What is the need to break a VI when a local variable in read mode is unconnected?

Question

What's wrong with an unconnected "read" local variable?
A control terminal (or indicator terminal for that matter) can exist on the BD without issues!
Use case: When I create a new control, I may want to drop a few local variables in different cases of an event structure to be connected later.
If in addition, I am planning to create a few controls, to be used in several cases, this is quicker than dealing with each case one at a time.
I'll just grab the terminal, create a local variable for it, copy it and then paste it in all the cases I need it in.
Then repeat with another control and finally, deal with the bunch of local variables in each case later on.
I would like to be able to run the VI without having to treat all cases, which I can't right nowm because the VI is broken as long as there remains at least one unconnected "read" local variable.
Again, I cannot fathom why the compiler would be unhappy with a "read" local variable unconnected to anything. Generate a copy of the data if you wish, don't use it, that's all!
I can see the problem with a "write" local variable, although I would wish an unconnected "write" local variable would be simply ignored. And probably the same should be done with an unconnected local variable: no copy should be generated.
Of course, a warning would be useful.

Answer 1

Then put it on the IE (assuming it's not already there) and see how it fares. Personally, I think I prefer the current situation for safety (i.e don't forget to use the code you actually put in), but I wouldn't be terribly broken up if it behaved like you want.
Try to take over the world!