As a p.s. to my last comment: I just tried a silly Gtk based tetris I had written some ago under MacOS: hit the green maximize button and it goes completely full screen. The only thing you still see is the mouse pointer - I am sure there is an API to make that invisible too, if one wanted to hide the mouse pointer.
I have never ever owened a computer where an application could not controle the whole screen. Yes, there are situations, where the OS supersedes the full screen apps input, but usually they are based on user interactions or notifications (which can be disabled).
>I have never ever owened a computer where an application could not controle the whole screen.
Yes you have. Every OS has chrome that cannot be disabled in full-screen. You may not regularly experience that, but it does. Imagine you're playing a video game and Windows Update throws an error. That will be displayed over your full-screen game window. It doesn't even have to be originated by the OS. As long as the OS is provided with an extended display, it has the ability to put things on top of whatever your app displays. It may not happen often but it does happen. That's the primary reason why dedicate I/O hardware exists.
As I wrote in the answer to your other comment, I have never claimed, that there aren't events that can cause the OS to supersede a fullscreen app. But by default, the OS does not display additional information on top of a full screen app. And perhaps we should discuss the same thing only in one thread.
I have never ever owened a computer where an application could not controle the whole screen. Yes, there are situations, where the OS supersedes the full screen apps input, but usually they are based on user interactions or notifications (which can be disabled).