I'd presume child processes would inherit the same restrictions as the parent process.
I guess a root process could remain privileged, the main restricted process could be a child of that, and that main process could ask the root process to spawn plugins. But, that'd weaken the model a bit.
I think it makes sense for child plugins to inherit restrictions at the time of the fork, not indefinitely. So the main process could spawn its plugins, then drop its own privileges.
The unixy solution to this is rather obvious. Main app runs at relatively-higher privilege. Main app forks proc for plugin. Drops privilege in the child after the fork. Then calls exec on the plugin. The plugin is stuck at that lower privilege, but still talks to the main app through a pipe etc.
Who, me? No, I wasn't. I was talking about the plugins keeping the high privileges (not raising them). And that would be because I assumed the plugins, like the main process, were trusted - my idea (like the proposed syscall) would be for the plugins to tame themselves, knowing what privileges they would need to work, and dropping everything else, so that they couldn't be used as an exploit. It wasn't to protect the system from the plugin authors themselves.
And my point is nobody who knows what they are doing would build it that way. Nobody suggested it ever work that way. OP's doubt on the subject was rooted in a misunderstanding of unix philosophy.
I guess a root process could remain privileged, the main restricted process could be a child of that, and that main process could ask the root process to spawn plugins. But, that'd weaken the model a bit.