/testforblock does not detect block-states

When using the testforblock command, it does not consider block-states.
As long as the block matches the specified block in the command, it will always be successful, regardless of whether the block-state matches or not.

In previous versions, if the block-state does not match what was specified in the testforblock command, the command would fail with the message “The block at {co-ordinates} did not match the expected block state.”

For example, if I were to place a button of “facing_direction"=1 and "button_pressed_bit"=false, writing /testforblock ~~~ stone_button will always be successful, regardless of whether a block-state is specified or not. All of the following commands would be successful.

/testforblock ~~~ stone_button ["facing_direction"=1]
/testforblock ~~~ stone_button ["facing_direction"=2]
/testforblock ~~~ stone_button ["facing_direction"=1,"button_pressed_bit"=false]
/testforblock ~~~ stone_button ["facing_direction"=1,"button_pressed_bit"=true]
/testforblock ~~~ stone_button ["facing_direction"=2,"button_pressed_bit"=true]

The returned message reads “Successfully found the block at {co-ordinates}.”
When a comparator is connected to a command block, it outputs a redstone signal when one testforblock is run.

I have (so far) tested this with various button types, levers and redstone wires, which all experiences the same issue.
I assume this bug is consistent across all blocks.

Command blocks that have not been edited since the bug was introduced have not been affected.
Once a command-block has been edited within the latest version, the bug is introduced.

This bug does not seem to apply to execute if block.