Charles Milette

It's not an issue with using statements. The gist of the issue is that since the namespace is unqualified, lookup rules will traverse the namespace tree backwards to find a...

I also think not using Microsoft.Windows would be the best move considering that according to https://github.com/microsoft/WindowsAppSDK/issues/1823, adding a `using namespace` within the `winrt` namespace is considered "best practice" (I would...

Why not use cppwinrt NuGet for everything? It is generating headers for system APIs too.

This already exists: https://docs.microsoft.com/en-us/windows/winui/api/microsoft.ui.dispatching.dispatcherqueuecontroller.createoncurrentthread

The options that DispatcherQueueOptions offers are: - The ability to create on a current or dedicated threads; - If making a dedicated thread, what COM apartment is used. I'm not...

It wouldnt be very future proof either way since any addition to the C API will require updating the WinRT APIs/types.

`Microsoft.Windows.System` will most likely lead to confusion (e.g. "why do we have 3 different `DispatcherQueueController` classes", "why can't I create a `M.W.S.DispatcherQueueController`"). We already have a mess with the many...

> The proposed API automatically work in e.g. rust if rust ever becomes supported. With a manual per-language solution we'd then lose feature parity and require more work to bring...

Just something: as an option please, cause not everyone wants GitHub flavored Markdown...

+1