It's already taken care of, since there are already namespaces. See, for example, ZDoom UDMF
ZDoom supports all namespaces defined in the base specification and adds two new ones:
These are not the same as I was referring to. To my knowledge, that section describes a value that instructs the editor and the game engine what type of map it's reading, so that appropriate changes can be made. For example, randy could put code into ZDoom that checks this, and if it sees that the value is "Skulltag" he could display an appropriate warning that some features may not work. Or he could make it alter some specials to work better in ZDoom. Or whatever.
What I'm talking about is the fact that if, within a sector definition, you decide that you want to put a completely custom field in (i.e. one not currently supported by ZDoom), a future version of ZDoom that implements that same name could cause trouble.
For illustration, here's a convoluted yet real-world example.
Let's say you're defining some kind of CTF mod for ZDoom. You write up an ACS script to handle all the special stuff you want in, and then in certain sectors you add the custom properties "BlueBase" and "RedBase". You can then check the value of these with ACS to determine which areas should be treated as each side's base for whatever purpose you wish for your custom CTF mod. You release it, everything works great, the world moves on.
Then, 6 months down the road, randy or Graf add some kind of support for funky color-related stuff in sectors (hey, I said it was convoluted) and add the sector properties "RedBase", "BlueBase" and "GreenBase" to support this. When you try to run your previously-working map in the new version, ZDoom reads these and expects to find an integer value, but instead gets a boolean. It reports the map format is bad and won't run it, or worse it treats it in an entirely unintended way and causes graphic anomalies that weren't present there before.
Unfortunately, I don't think it's wise to rely on the map authors to police themselves by creating names that are unlikely to be used in the future. It's all well and good if every author out there decided to use stuff like "MyAwesomeCTFMod_03-2009_v1_BlueBase" to prevent future conflicts, but it's just as likely that someone not knowing any better will use stuff like "SlopeAngle", "RedValue" and even "J" instead. This can only lead to trouble, in my opinion.
I don't know if this would have to affect the base UDMF spec or what, or if the engine should be required to enforce it, but it might not be a bad idea for the editor to automatically preface these kind of parameters with "custom." or something. I guess you'd have to allow the user to override that for the purposes of case 1 in CodeImp's post... I don't know, it just seems like this is trouble brewing and it's better to be solved early than later.