A suggestion like this comes up occassionally and the question is always "why do you think that this specific function should get this special terminal which other functions don't"? Unless you can answer that, you won't see this happening, because this logic can apply to any function.
Also, I wouldn't spend any effort on this if I was you, because even if you did have a good reason, I doubt that NI would do anything to change globals, particularly the writing aspect of them. Like in most other languages, global variables are not liked by many people, mainly because it's easy to create race conditions with them, and I'm guessing they are unlikely to have any changes which don't deal with that aspect.
I think that the readability of the diagram is better with the consistent notation for "execute this code or not". I deeply dislike Boolean terminals for "do this or sometimes don't do this" on most APIs. I am fine with Booleans that control how the node operates, but skipping its behavior entirely is something I save for only the most extreme encapsulation cases. I'd rather see such things noted on the diagram using a Case Structure. That's especially true when -- as is often the case -- more things than just the one variable write are dependent upon the same Boolean condition.
(This is my personal opinion as a G user and should not be taken as indicative of LV R&D's position on this idea.)
Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.