Re: I think that UI toolkit should use native widgets and near zero cost FFI.
If the target audience is cross-platform, that's hard to pull off. Each OS's native GUI engine is too different. Emulating a common target behavior is usually better (until a good general GUI standard comes along). Maybe your particular need is not cross-platform, but Lazarus's goal is.
FWIW LCL (Lazarus' framework) emulates the Windows behavior (there are even some reimplementations of Windows functions in non-Windows platforms to assist with that) since the API "descends" from Delphi's VCL which is Windows-only (and IMO it makes perfect sense that if you need to emulate some OS's behavior to focus on the most popular one).
The end result is obviously that under Windows things work great, under X11/Linux with the Qt (i think both 4 and 5 are supported nowadays) and Gtk2 being generally fine as they mostly behave like Windows (especially Qt) and the worst being Mac support since it is so different from Windows (that and the Mac backend was originally written using Carbon as that was easier to interface with FreePascal and still to this day is the most robust backend for Mac, although in reality both the Carbon and Cocoa backends aren't that great). And of course the programs despite using native widgets, still look like Windows programs on a Mac dress ([0] is an old screenshot from my 3D world editor compiled under Mac, the Windows-isms are clear). You can obviously try to make things look more Mac-y (and i did try a bit) but you need to do so much (and in a different branch since some changes can be very invasive) that IMO isn't worth the effort unless you really want to get that "Mac look" (but be prepared for a lot of custom code and changes to bypass LCL).
Making it fit every OS well is indeed a tricky task. Perhaps the option of using native widgets can be given. Actually, ideally there'd be 3 choices for developers: 1) A default single uniform style for a given widget(s), 2) Emulation of OS-specific styles, 3) Native widgets. But providing all 3 without making a mess or bloatware is easier said than done.
The tricky thing about cross-platform UI dev, when considering macOS, isn't just about the widgets and so on. It's things like placement, hierarchies, etc. Like you said, easier said than done. To demonstrate for those who aren't sure:
Say Joe Bloggs wants to make an alert window to confirm if the user wants to save the document, but needs to add custom text and graphics so can't rely on a default implementation on each platform. So he makes an alert window, looks great.
Except his design is utterly confusing for macOS users. See, on Windows (and plenty of Linux environments), the Save and Cancel buttons would be centred on the window, and Save would be at the left. On macOS, Save and Cancel would be aligned to the right, and Save would be the right-most button.
Okay, so that's a pretty easy thing to solve with a cross-platform toolkit. Instead of defining the placement of buttons, you just define the text and action for the default button, the text and action for the cancel button, and they'll be put in the right place for every platform. Easy.
But that's such a small example. Try scaling that to the way macOS and Windows/Linux differ in the use of view hierarchies. Windows-style tab controls vs NSTabView; Windows/Linux-style tabbed, left-aligned settings windows vs standard macOS-style centre-aligned preference windows with NSToolbar at the top; each window/section of an app having its own menu bar as opposed to macOS having a static menu bar whose items enable/disable depending on context; MDI vs document-based apps; the fact that macOS apps can still be running even with no windows open, meaning that certain parts of the UI can still be opened, and your UI must account for this despite another window that you would expect to be open (on Windows or Linux) not being in memory at all.
To an engineer, these might seem trivial or not that big a deal. To a user, that's potential data loss.
When it comes to the controls, etc it always wraps them, but the exposed API is based on VCL which has several Windows-isms and those Windows-isms are replicated to other widgetsets. One example would be the reliance of several controls (like toolbars, lists, trees, etc) to image lists (which is basically a Windows Common Controls thing that is used in Delphi - Lazarus just keeps the API but reimplements those common controls). On a lower layer, LCL widgetsets implements several Windows API functions (often accessed via the LCLIntf unit or the widgetset itself as methods). As an example this file reimplements several of Windows API functions in Gtk2:
Note that all widgetsets implement these methods, even the Win32 one (which instead of reimplementing it just forwards the calls to the real Windows API).
If the target audience is cross-platform, that's hard to pull off. Each OS's native GUI engine is too different. Emulating a common target behavior is usually better (until a good general GUI standard comes along). Maybe your particular need is not cross-platform, but Lazarus's goal is.