DOSBox currently stores state in global variables, and SDL itself is designed to only track a single output view at a time. These design decisions prevent us from opening multiple DOS sessions side-by-side.
Rather than recode the hell out of DOSBox and SDL, the cleanest solution would be to move DOSBox into a separate child process for each window that talks to a main Boxer parent process (which would be responsible for event dispatch and actual rendering of the DOSBox output).
This would have the side benefits of letting us gracefully cope with DOSBox crashes (kill the process, not the application) and not link to DOSBox/SDL directly (giving us breathing-space from GPL licensing issues and allowing Boxer's code to be dual-licensed as MIT.)
However, the difficulty would come from feeding interface events to the DOS child processes and feeding their output buffers back to the parent Boxer windows. Latency would be an unknown factor in this.
Also, I have absolutely no idea where to begin with cross-process programming :)