Most of it is automatically handled by the native interface of the OS when it renders the UI. Some cases have to be dealt by the wrapper library developer, and some of it has to be done by the developer creating the app using the wrapper library.
For example, a Window usually has the default UI elements of a Title Bar, the title text, Max-minimize buttons, window resize handlers etc. In Windows, this is rendered with the max-minimise buttons on the top-right corner, and the title left aligned in the title bar (if I remember right). On macOS, the same Window will be rendered with the max-minimise button on the top-left corner and the title centered in the title bar.
When you create a window on MS Windows OS using the Win32 API for it - http://www.winprog.org/tutorial/simple_window.html - the rendered window will be, by default, according to Microsoft UI / UX guidelines. Similarly, when you create a window using the cocoa framework on macOS, the window will be rendered, by default, according to the UI / UX guidelines of Apple - https://github.com/lukakerr/NSWindowStyles .
This highlights how some UI / UX guidelines are baked into the native frameworks.
But if the wrapper library developer wants to offer some multi-platform custom UI component not available natively, they will have to ensure that the component is compliant with UI / UX guidelines of the OS they are rendered in.
(If you want to see this in action with an actual wrapper library, check out Lazarus IDE - https://www.lazarus-ide.org/index.php ... create a window on it on MS Windows, Linux or macOS with its GUI designer and compile the code to the see the native window it generates, on each OS.)
Most of the other things described in the article are also already available in the native GUI frameworks. It would make more sense to extend and enhance what is lacking, rather than re-inventing the whole thing again (which, as you noticed, can be a pain if you have to conform to different OS guidelines).