It is part of the user interface of the server as it is.
It only gets hokey when you reference files as it’s all remote.
Except shell itself is an abstraction over a computer by encapsulating system APIs.
The point of the shell is that it's how you issue commands to the computer. You (or GP) want to make the commands independent of the shell. OK. How do you issue your new shell-agnostic commands? How is the computer supposed to understand them?
For that to happen, you'll need to implement a shell in the exact place where you just removed the first one.
* the command editor * the command interpreter/parser * the fork()/exec() calls
I think you're talking about the fork()/exec() calls. I'm primarily talking about the command editor.
(I don't think your three-part listing makes sense: commands are the input to the shell, and system calls are the output. But you can't separate them -- without input, what output are you producing?)
And now, on the client, we have a command editor running which accepts keystrokes and produces commands.
But the client runs on a different machine. It doesn't know what commands the protoshell over on the server can accept. How does it know what commands to produce?
The app captures syscalls working on FDs and forwards those to the remote side. You could do that in much more clever ways. You can also do it in hacky simple ways like for example ansible does, by just running each command remotely.