Let me argue here that many of the uses of environment variables are less necessary in a capability system, but that new uses may become important. I presume here that any such construct is a namespace object and is accessed via a capability.

On a Keykos command line one would often invoke a factory for a new instance. The factory requires two space banks and a meter. There are no environment variables in the elementary Keykos shell. The string “SB,M,SB” is still built into my reflexes. A space bank or two and a meter would have been natural candidates for evs. This small problem goes beyond the command line finger muscles, however. A fair amount of Keykos code is for building other Keykos structures. It pays the cost of passing these three keys as well. We considered a resources packet, perhaps as simple as a node with the three keys.

While we are at it there are other facilities that guest code requires. What does a code developer on one system ship to another system? At least some code that builds things; I will call it Bcode. The Bcode will certainly require a space bank and a meter. It will usually also require requestor keys for some local conventional factories. This requires a namespace in the meaning of the current mail discussion. In Keykos there is a generally available directory of requestor keys and similar keys which it is safe to share. This whole issue leads to the idea of apartments which Bcode can call its own, presumably undisturbed by a landlord (machine owner, operator or user) and with access to local resources sufficient to build a factory or fort adequate to serve its employers. (Terms purposely vague here!) Exactly the same problems arise with portable, mobile or itinerant agents that wish to bring behavior (code) across a wire to a new site.
Unless local infrastructure is employed by that transported code there will probably be no advantage over having merely sent a proxy. There are difficult problems of quality of local services. These problems are much more difficult in conventional systems, however.

What I intended to write about here is some environment variables that are not needed in a capability system. In Unix the yield of “printenv” for me shows many values of interest to just one program.
In a object system those values should be encapsulated in my instance of that program. PATH, MANPATH, SHELL and many more are like this. Other values seem to be secret notes left by one app to another. These notes would be less vulnerable if conveyed by a capability.