IS vs. IS NOT Trigger Bug?

For those who may read this thread later, I would like to point out that this statement:

Programmatically, the two trigger statements (When the state of all rectangles is not Normal / When the state of all rectangles is Activated) are equivalent logical operators

is not always necessarily true. While it is true in the case of the slide you attached, if the rectangles have other states, they could be in a selected state, which is neither Normal, nor Activated.
Your question: "Is this a IS vs IS NOT bug?" isn't broad enough in scope to encompass the true problem, nor the answer. The problem is the way Articulate has designed and executed "When state of XXX is ..." Most of us recognize that "when state is" is not an action, and shouldn't be capable of initiating a trigger. So we assume that what it really means is "when state becomes", and write our triggers accordingly. But SL didn't implement it that way. It doesn't have a true listener, that is listening for states to change. Rather, it seems to sporadically check and see what the states are, and use the states as conditions. My experience is that the internal trigger really works like "Take action when checker checks states if all the rectangles are Activated." So "when state of" works sometimes, and not others. It has traditionally worked only for a maximum of 4 or 5 objects at a time. Further complicating things is the fact that the quasi-listener at best listens for objects arriving in states, but not leaving a state (as you found out.) That is why the "is Activated" works, while "is not Normal" doesn't.
Another potential problem that you don't have, but a potential reader might, is that all the built-in states are overlays of Normal, and thus all report themselves as normal. So IS NOT Normal doesn't work for any of them.
So I know; "When all of XXX are state YYY" is really glamorous and easy to write, but I try to resist. If it absolutely must work every time, I will write "Change state of Next to Normal when slide 1 changes if state of rectangles 2, 3, and 4 are activated". The listeners for variables are always listening and aren't limited in numbers.

Your response kinda glosses over the issue that at one point, that conditional trigger did work. Now, it doesn't. It's not that I couldn't code around it (I already did, and in a more-absolute way), it's the fact that for others who may have used the IS NOT state of an object as a trigger (when it was functional), Articulate, in its infinite wisdom, quietly removed that functionality. The next time they open and republish a previously-working course, it will hang at that point.

It would be akin to taking my perfectly-working car in to the shop for a simple oil change, and they, without fanfare, "fix" the way the steering wheel works, by making the wheels turn in the opposite direction of the way the wheel turns. But only when travelling above 55 MPH.

Joseph, I can confirm that "is NOT Normal" does not work. I have had the same problem and had reported it. Please report it, so it's not coming just from me.

So if I understand it correctly, what you're saying is:

Old trigger reads:
"Set the state of the NEXT BUTTON to NORMAL when:
     "the state of all RECTANGLES (sliders) is not Normal"

But if you change it to make it "positive" it works, so you alter the trigger to be when the state of all SLIDERS is (are) ACTIVATED

It has been a year, and I'm still fairly new to SL, but can confirm this bug still exists.

Hi Miles, 

I'd like to take a closer look at this behavior to see if this behavior is a bug that needs to be reported to the product team. Would you be willing to share a copy of your project file here or in private through a support case so we can verify the behavior? We'll delete it as soon as we're done testing. 

Hi Joe,
If you download the original file that @Joseph Francis added, that one works.

If you preview directly when you DL it, it doesn't work (click on all 4 sliders, the next option is not available). But if you change the trigger to be "positive" (is Activated vs. Is Not Normal), it works again.

Hi Miles and Nejc, 

Thanks for sharing additional details regarding the behavior. I checked Nejc's support case and it looks like we still have an open bug that causes the 'Is not normal' trigger condition to not work properly under certain situations. 

I've added this support case to the bug report so we can notify everyone when a fix is released. For everyone's reference, here's a quick look at how we tackle bugs.