I did just the quickest of tests myself, so this is only a suggestion, but based on the descriptions from
and looking at the Starling constructor's source code, here is my take:
when you call the Starling constructor and don't pass the fourth argument (or pass null) for the specific stage3D instance, Starling will default to using
stage.stage3Ds and then at the end of the constructor request a context3D be created for that stage3D.
So if you want two Starling instances and each associated with a different stage3D, pass explicit fourth arguments using
stage.stage3Ds for one and
stage.stage3Ds for the other, and then track and use those two Starlings/Stage3Ds, changing or overlapping the viewport of each Starling instance (which sets the position of the stage3D too) (that article says current impls wont blend between stage3Ds from front to back but only overlap) and I assume you would be able to specify a viewport rect that would map to how each of your two screens are specified (hopefully in a globally shared coordinate system).
Seems you can have up to 4 stage3Ds available but some hardware might not even have two, so best to check for null before trying to use one.
In addition, this technique doesn't solve your 2 windows requirement, but I was wondering what happens if you took the app into fullscreen mode with:
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
does the stage fill both of your monitors? I was thinking that if it did, you could map the two different Starling viewport rects appropriately to each monitor