I don't think bug 1588412 will fix this unfortunately.
I haven't debugged this fully, but if we're getting into a process switching loop, then I suspect that we're trying to make the process decision in multiple places, and coming up with different results.
I think what's happening that is DocumentChannelParent is calling into http-on-may-change process, which picks a process to use, and gets the 'real' URI from the actual channel (which I think will be the resolved http manifesto UR).
Then we setup a new process/docshell, and attempt to load there and then hit this process check - https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/docshell/base/nsDocShell.cpp#9253
That one is just using the URI from the DocShellLoadState, and could likely be the moz:// one. I suspect that'll then come up with a different answer, and we'll attempt to restart the load in a different process.
The long term fix is to get rid of the old process switching checks, and only ever use DocumentChannelParent. In the short term, maybe we could check for aLoadState->GetPendingRedirectedChannel() to detect when the current load is one that has been switched to us, and not check again.