Good question, @bgrommes. The native-versus-uniform tension is real, and you're right that code assuming one platform's focus behaviour could see something different on another. But it cuts both ways: code that assumes Windows click-focus behaviour is equally surprised on macOS, and that's the situation today - the current uniform behaviour is itself the bug on the Mac, where every native app leaves focus where it was when you click a button. So the real choice is which side to diverge from: each platform's own conventions, or uniformity. We go with the platform, same as a native Mac or Windows app.
In practice the difference is narrower than it smells. It only shows up on mouse clicks (Tab navigation is identical everywhere) and a Button's Pressed event fires the same way on every platform no matter who holds focus. The only code that can observe the difference is a FocusLost/FocusReceived handler firing during a click, and that code doesn't need a new property to detect it: the events themselves are the detection. They fire on Windows and don't on macOS once the fix lands, so code can react to what actually happened. And for code that must adapt up front, System.IsMacOS / System.IsWindows already say which platform you're on.
A per-control override is a fair suggestion with real precedent (AppKit's NSButton has exactly that (refusesFirstResponder), and Swing has setFocusable) and I've noted it on the tracking issue. My hesitation is shipping API before anyone has a use case for it: once a property ships it's effectively permanent, and questions like "does it also affect Tab order?" are much easier to answer against a real need. It can be added later without breaking anything.
And no apology needed, @Piero - the TabStop detail was genuinely useful. It showed the Tab focus system was behaving, which helped narrow the problem to clicks specifically. Thanks again for the clear report!