Testingfor score command block glitch

Confirmed, see screenshots

um. yes its TRUE that comparators do not stop receiving a signal after successfully running a command of any kind...but they always did that? i'm pretty sure its intentional.
they essentially become extremely weak power sources that verify that the LAST command that was run was executed or is "true"(where as no signal means false or invalid)

its not nessasary to destroy the entire command block to end the output- it just requires the command to fail. if you had 1) rewrote the code to something wrong or 2) moved outside the radius of 3 that was tested for, AND THEN powered the comm.block again it would have stopped the output.

i just tested this myself using the same command in the screen shot and it seems to work just as it always has.

I did not post the screenshots [Mod] Kumasasa did. One of the commands I used were tesetfor @p[score_PointA=0] (score_PointA=0 is in square brackets but it doesn't show up).

before i start, i apologise for necroing this thread. i saw it and thought it'd contribute.
once i realised i had the same issue (where output=true), i learned that the command block needs to update, which means it either needs to be replaced with a clone of itself or test false.
setblock ~ ~ ~ command_block 0 replace (Command:"tp @p ~ ~2 ~")
replace the curved brackets with curled brackets:
{ }
the above command will replace itself with a command block that would teleport the nearest player up 2 blocks.
the '0' in the command above is for things like wood and wool where there are different versions of it separated by a single value. for example: white wool is version zero.
fun fact: the transparent 'air' block can also be used instead of 'command_block'. i quite like creating button-like pulses by making a command block produce a 'redstone_block' and a few ticks later another one that replaces it with air.
hope i helped!