In that case if I add a Map to a namespace, you won't be able to iterate over the keys and find out ones which have a '.' character. How do we handle those cases?
Are there any cases of dynamic maps right now that don't look like function calls? In my mind, any dynamic variables should look like "a.b.c.d(...)", where "a.b.c" is the namespace in which you can find the variable/function "d(...)". I think this is consistent with the way these are added to namespaces right now? The only problem is if you want to have the function called "d.e(...)" in the namespace "a.b.c", which I don't think should be supported. Is it unreasonable to say you can't use '.' characters in naming those functions? If you really want to call "a.b.c.d.e(...)", then have your dynamic namespace be "a.b.c.d" with a function "e(...)".
WRT iterating over the maps: to be clear, I would prefer the implementation be changed to how the patch is now: if you add "b.c" to "a", then thats how you have to retrieve it; therefore you should add "c" to "a.b" if you want "a.b.c" to be resolvable. Perhaps if you have a specific map which you know will have '.' separated names (like request), there should be a flag in the add* methods for whether to check or not.
Nonetheless I understand that I might be the only one that cares about these things and that these changes are not backwards compatible. Still, the API explicitly mentions that it is unstable so perhaps changing it slightly is not a big deal. I think this will make some steps towards solidifying the API. The other thing the patch does towards this goal is to make consistent use of what the null and empty string "" namespace refer to (the patch follows the convention that null is the top-level namespace, and empty string is treated the same as any other string).
I think this is a good change to make. However, we need to be careful with this. With the current way of resolving variables, one may get a lot of false alarms.