If you are trying to say that when you compile against a newer DotNetNuke.dll version that your module will not run on an earlier version then you are correct.
But, that is your problem. You should always compile your modules against the earliest possible DotNetNuke version that it can be supported with.
Even if you want to use version 5.5 of the CE in the future, but there is not a version 5.5 of PE, then you should set the version back in your own development environment (unless of course you require a new feature that is not in the prior versions).
CE and PE will still be developed in lockstep, so the problem you are trying to raise is not a problem.
Now, if they break Binary Compatability between the two editions then there will be a problem, but from what they are saying, they will not do that.
That being said, a global constant does break binary compatability, but only if you are referencing it. And I don't think you are referencing that one.
My advice to the architects at DNN Corp. is to get rid of all of those global contants and make them configuration items.
I argued in several core team chats long ago that those global constants were bad and equivalent to hard-coding what should be run time variables.