It's not unavoidable / impossible. We (can) have the technology!
If you want a new environment variable added, or one altered, it needs to be sent out to the UI process that starts new tasks (like shells, applications and so on). To be extra clever, this new environment message could also be passed to running terminal emulators as well (so that if you open a new tab in a running app, the shell started in there will also obtain the new variables)
Environment change to send (something) to UI process(es). Plural here -- these could be window manager, shell, or applications. Since application subsumes window manager and shell, we will ignore that. Unless the application is forced to say "I am interested" to (say) systemd. Or dbus.
Then, accept the environment changes. But, those will have to be filtered -- this could be user input. Indeed, the application may have an application starter, and one the jobs of the application starter may be to filter the environment. The application starter may never expect an environment change, but the application started may (in our "new world" API). This could result in security holes (especially for large daemon processes). Interestingly, the main purpose of this change would be to allow the environment to change dynamically for those daemons.
The "extra clever" is the easy case -- make changes in .bashrc This will get read by new tabs in your terminal emulator.
Having an application starter that is responsible for the environment is the (current) solution. Of course, this does not permit environment changes. But these are impossible anyway -- int main(int ac, char av, char envp) implies that the environment passed to main must not be altered. Of course SUSv3 doesn't specify it, and getenv() putenv() should be used. Hoever, extern char environ; is allowed, which is the same as char envp.
So, an application can do char path = getenv("PATH");
to obtain the PATH. After which, char path will not change (as long as getenv(), setenv, unsetenv() or putenv() is not called, and environ is not written).
Which means that it is very difficult to "inject" a PATH change -- it should be impossible. Another mechanism must be put into place for this, but POSIX semantics should be maintained.
In my code, I tend to do strdup(getenv("PATH")) or something along those lines (note that getenv() may invalidate a previous getenv() so it is not safe to store the result char* of getenv()).
If you want a new environment variable added, or one altered, it needs to be sent out to the UI process that starts new tasks (like shells, applications and so on). To be extra clever, this new environment message could also be passed to running terminal emulators as well (so that if you open a new tab in a running app, the shell started in there will also obtain the new variables)