I say modernise, but this has been the preferred way of using fullscreen since macOS lion 10.7, 16 years ago when they introduced spaces (effectively separate desktops for fullscreen apps)

The current implementation is really just borderless fullscreen, creating a window the size of the display. This can easily cause inconsistencies as it's possible for users to use toggle the modern spaces fullscreen via a keyboard shortcut, the apps menu bar, or the fullscreen button on the window titlebar. When they do this, the SFML app goes to a fullscreen space, but SFML's implementation is not aware of it and still thinks it's' windowed.

This implementation detail wasn't really exposed as there's no way currently to check if an SFML window is fullscreen, it relies on the developer to track it themselves, however with the upcoming PR to expose the fullscreen state in #3501 this issue is even more apparent - getState would return Windowed when for all intents and purposes the window is fullscreen.

So there's three options to solve this:

• Maintain the existing behaviour and add code to disable the fullscreen button, menubar and keyboard shortcut. This creates a bad experience for end users and diverges from the typical Mac user experiences
• Give the user the option to either use the modern fullscreen space or the legacy borderless windowed fullscreen
• Replace the existing implementation with fullscreen space

I have gone for the last option, as it fixes the bugs, tidies the implementation and requires no API changes. It guarantees that fullscreen specific behaviour such as resizing the window programmatically behaves correctly in all cases and users won't be confused by SFML windows having multiple different fullscreen states

For comparison, SDL offers a hint to choose which mode: https://wiki.libsdl.org/SDL2/SDL_HINT_VIDEO_MAC_FULLSCREEN_SPACES

As a bonus bug fix, we no longer have to guess about the fullscreen state of windows that are created by passing an existing native window handle