I believe that another (fourth) focus model is missing here: the one provided by the "True X-mouse Giszmo" tool.
The tool enables the variant "Focus follows mouse without autoraise" -- but also without raising the window even when clicking into the window! This can be very useful on dual screen setups with some application spanning over both monitors, and another application only being present on one of the monitors. Then, you can work inside the application that spans both monitors without inadvertently covering up the application on the other monitor.
Maybe someone can put this into the correct wording and format on the parent page.
It should be mentioned that click to focus doesn't necessarily mean that the mouse input is only taken by the current window. I've found in most X11 window managers one can do things like scroll windows not in focus, largely because while focus-follows-mouse may be common, to the mouse system itself in X, focus is completely irrelevant to the mouse. As it should be, since the mouse is a purely location-based input device, what th mouse wants to do where shouldn't be a question of focus. When one wants to scroll information in a window off focus they move the mouse over the window anyway. it is pretty obvious what window it was meant for.
I can't speak for Mac OS X, but I know Windows still does it purely by focused windows, and even a lot of focused components on focused windows still don't support scrolling.
I think it would be interesting to include a brief session describing the process of shifting focus in those implementations. Do they use the position of the mouse as an indicator for the OS to expect a possible shift? How are requests processed to minimized delays between the input to shift focus and the actual shifting? This is clear in the "focus follows mouse" but not so much on "click to shift" mode. 18.104.22.168 (talk) 23:52, 24 August 2012 (UTC)P-L