One thing newbies often ask, is why can't they write a shell script which changes the environment or directory of their running shell. The answer, of course, is that you can't, without sourcing it.
People also ask the same question about Windows, and even DOS before it; there you actually could do it from a batch file, since CMD.EXE/COMMAND.COM effectively sources all batch files, it doesn't run them in a subprocess – but the same issue occurs if you write a program in some other language than batch, it runs in a subprocess and so can't modify CMD.EXE/COMMAND.COM's environment. (People resorted to some tricks though, like having a BATCH1.BAT call their program, and then afterwards call BATCH2.BAT, and their program modifies BATCH2.BAT on disk).
Actually on DOS, there is a way to modify COMMAND.COM's environment – COMMAND.COM installs an undocumented interrupt, INT 0x2E, which you can use to send commands to COMMAND.COM to run. So you can actually modify COMMAND.COM's environment. (Only the root COMAMND.COM installs a handler for INT 0x2E, nested ones do not.) Of course, due to no memory protection, there are also nasty ways of doing this, like modifying COMMAND.COM's memory. (And changing COMMAND.COM directory isn't an issue, since under DOS, the current directory is system-wide, not per-process.)
I was thinking, you could do something like "INT 0x2E" in a Unix shell. Create a Unix domain socket, and the shell listens for commands on it to execute. Put the path to the socket in an environment variable which is inherited by subprocesses, e.g. SHELL_CONTROL. Then, a subprocess can inspect and modify the shell's environment, working directory, functions, aliases, running jobs, etc, by reading/writing the Unix domain socket mentioned in SHELL_CONTROL.