You are correct about the behavior of the simple example you describe, but your consumer loop is not the same as that example at all. As soon as the consumer while loop begins a new iteration, your control values are read. Then, whenever the dequeue finally gets an element, all of the input values (probably with the exception of "Flame Sensor Value(%)") will be stale. I haven't looked any further into the logic because I'm not familiar with the requirements of this example, but Todd is 100% correct about the behavior of the controls in the consumer loop.
I don't understand why you put the "Flame Sensor Value(%)" terminal after the case structure in a sequence structure, or why you have a 50ms delay in a blocked loop.
Wrapping the controls in a sequence structure, for example, will will ensure the correct values are passed into the case structure:
Personally, I think that your consumer should not be interacting with controls at all. The producer should read values, and pass the data with the command to the consumer. Since you have a display loop, the consumer loop shouldn't have any terminals, references, locals or property nodes in it. For example, you have a subVI which uses a references to change the blinking property of the Pilot boolean.