It sounds like you need some kind of... trapper keeper
Well played sir,
I see what you did there 
Seems like the trap doesn't touch any of the registers---could you save enough information in D1-D7/A1-A7 so that the routine at (A0) can figure out what it needs to know to restore the old context?
ISTR that the folks at CMU who made that Apple Lisa demo talked about using some kinds of privilege escalation---but they never detailed what they did.
Yeah, so this call is used pretty often within Lisa Office System. I'm not sure why they needed this mechanism at all, since as soon as you invoke a trap, you're inside supervisor mode and context 0 automatically, they could have then dropped privileges using a write to the SR on the way back or through RTE. So it's yet another kludge that's also a security hole.
So the MMU will switch to whatever context segment1 and segment2 latches are set to when the 68000 Supervisor flag is zero, and will always go to context 0 when the supervisor flag is 1. So you can actually use a 2nd call to this trap from supervisor land to return back to where you were. So you don't have to worry about the MMU context switch back to your code, you only need to somehow pass a return address to your target code. You can get this via LEA pointing to where you want it to return to, and pass it through one of the A registers.
Or you can do the record thing where you fill out a struct (record in pascal speak) with whatever params you want, including the return address, save this in common space (memory shared by all 4 MMU contexts) and set a pointer to this record via one of the A regs, such as A3, set A0 and D0 to your target address and SR, and trap.
The only weird MMU context is the SIO space, for which there are MMU functions/procedures in the OS itself, so no need to do that manually.
To find common space, you can compile in a call the MMU dump routine from LisaEm and examine the output file, I remember seeing that there are large swaths of space shared in all 4 contexts. These are always going to be in the same address spaces.
Rant about efficiency:
In LOS there's many ABIs doing things such as the Aline traps and TRAP #5 mechanisms. i.e. pascal libs that call a trap than then resolve to a JMP table offset by D7 (or by the 2nd word following the A-Line opcode) and each layer makes heavy use of the stack making each call very slow.] Some of this is likely so kludgy possibly because it was written by different people at different times, backwards compatibility with LOS1 and LOS2, introduction of QuickDraw, and perhaps back and forth with the Mac guys and possibly needing some compatibility with that.
I'd chalk a lot of this up to meeting deadlines and making stuff work rather than making it efficient, and clean.
It also seems at a cursive glance that the OS system calls aren't fully documented, but rather their equivalent pascal library modules are, so what's in the Operating System manual PDF isn't the true OS. Keeping those internal JMP tables for both the TRAP #5 and A-line mechanisms somewhat makes sense if you want to keep a stable ABI between releases, but then all the layers around them make it very inefficient. Some of this is possibly due to the pascal compiler not optimizing to use registers rather than the stack when making procedure/function calls, etc. but that's neither here nor there.
As I reread the OS manual for LOS, I'm convinced these guys were familiar with Unix and implemented something similar. The odd thing is the use of - instead of / as a file system separator, and the device names hanging off the file system is a lot like Windows NT, so possibly there was some VMS influence there too? (i.e. see EXEC call, named pipes, directory reading calls, etc.)
