Ogre is putting the THIS pointer of D3D9RenderWindow into GWL_USERDATA, which gets carried through the message loop, so we could not put a Win32Mouse pointer in there. Although we could maybe store the Ogre value and replace it with ours but if Ogre changes its then we would cause problems with Ogre.
I was thinking that a kludge to retrieve the state of the window (windowed or fullscreen) would be to find a message such as WM_CREATE, retrieve the D3D9RenderWindow pointer and store it inside Win32Mouse. I tried to find the code to toggle between a windowed and a fullscreen mode but could not. My goal was to see if they (the Ogre team) delete the win32 window, in which case a new WM_CREATE message would be sent, or if they simply create a new D3D device, in which case I would not be notified that there was a new "window" and would not know to retrieve the new pointer to D3D9RenderWindow. Another approach would be to create an access function to tell the Mouse class of the new state. This aspect, of detecting whether we are in windowed or fullscreen mode is still under development so nothing to propose/suggest yet.
My thoughts on the message loop is that another one may be useful to handle keyboard input, especially the WM_CHAR messages which result in UTF-16 characters. And there's also the elusive WM_UNICHAR message that results in UTF-32 characters but I have as yet been unable to receive it; maybe it's only received when an external application (an IME) sends a message to the application. So rather than having two message loops, a single one could be used to handle/intercept all Windows messages.
I bring up the WM_CHAR message because from what I've read on this topic keeps stating that DirectInput is good for responding to triggers (ie hit the A key to attack, SPACE to jump, etc) and WM_CHAR messages are the best for handling text input such as chat. But keyboard input is for later.
Being integrated as it currently is makes it easier on the programmers; they have nothing new to add. However they are stuck with a feature that is always "on" without the ability to turn it off. It also hides the yucky static pointer to Win32Mouse, which is needed unless this type of access/retrieval is added:
OIS::InputManager::getSingletonPtr()->getDevice(OIS::Type::OISMouse, 0).
OIS was so far directed toward gathering input from peripherals. Using a message loop (under Windows at least) would create a new type of input, such as an environmental or platform input. As you hinted at, these messages could be packed into a new class and programmers integrate the appropriate code within the functions of this class, such as a Platform::Activate() which would include my acquire(true) function. But this requires knowledge of the workings of the various platforms, what messages they send off, which are common and which are platform-specific. This seems like an interesting idea.
My initial goal was to better integrate Ogre windowed applications within Windows and my changes accomplish that. The only part that really must stay inside the Win32Mouse class is the acquire function. The message loop handling could be taken out and placed within a platform input class.
