raw-window-handle recently changed their API to use the names of the toolkit instead of the platform. E.g. Windows -> Win32 and MacOS -> AppKit.

This is done because the mapping is not 1:1, an example in winit is Wayland vs. X11 (X11 can technically be used on MacOS as well), another prominent example is that UIKit applications can be used on MacOS using Mac Catalyst. Additionally, AppKit applications can technically also run under non-macos systems using GNUStep (though winit likely won't work out-of-the-box for this), and I suspect similar compatibility libraries exist for the other toolkits.

winit is only built to handle the most common platform/toolkit combinations, but maybe we should start to change this? It would allow using winit in more situations, and would also open up for adding support for choosing Qt or GTK (the fairly popular druid-shell and the fork tao both use GTK, if that's any indication) as one's backing toolkit.

Concretely, we could begin by renaming things:

• Documentation ("Platform-specific" section -> "Toolkit-specific" section)
• Extension traits (WindowExtIOS -> WindowExtUiKit)
• Directory/file structure externally (e.g. platform::macos -> toolkit::appkit)
• Directory/file structure internally (e.g. platform_impl/windows -> toolkit_impl/win32)

In the future we could then expose features to enable each toolkit, with sensible defaults set per platform (see rust-lang/cargo#1197 (comment)).

Downsides include teachability (most users probably don't care about the distinction), git conflicts (there are a lot of open PRs that would potentially be affected by a rename) and churn (any usage of the platform module would have to change).

Opening this for discussion, there are other ways to solve the Mac Catalyst and GTK problems!