One other possible way, that I am getting ready to explore is to run the viewport in a separate thread and use delegates to access functions between threads.
If this is done, there shouldn't be a problem of DGDK.Net monopolizing the input. One of the reasons why it does, is because of the way .NET and events work. Every time an event is called, the call gets placed in a stack, and then the calls are handled in order. If a sub or function is running when the call is made, then it executes the callback function for the event when the current function or sub is done. However if you are running in a game loop, that current function or sub is NEVER done so the events never get acted on. However if this was all, just adding an Application.DoEvents() in the game loop would fix it, so it is a combination of that and DGDK taking over the input.
Operating the game loop in a separate thread might fix this, but you will have to attach the viewport from within the same thread as the game loop or it will just make a new viewport window instead.
As I said, I don't have an example of this yet.... but I will be working on it since I need it for my current project. One other possibility is running the viewport in another appdomain, but that gets a little trickier.
Design documents?!? What design documents??? I thought we were just going to wing it!!!