First off: I know that a question title containing "recommendations" screams for downvotes and "not-constructive" flags, but I'd be happy if you'd read this first and considering that I'm facing a concrete problem in terms of accessible learning material/documentation.
ATM I'm trying to expand my existing application from Linux to Windows. Structure basically consists of a backend-core containing several static native C++ libraries, which I'm calling from within a frontend project (C/C++ GTK with bits of other languages). IMHO it should be a pretty common plan to expand this kind of project to other platforms by using the core-C++ libs and just plugging them into different platform-specific frontends. Now this would be an UWP project in this case.
What confuses me is the seemingly inconsistent, right-now-transitioning landscape of interop-strategies with C# by Microsoft, thinking of C++/CX and C++/WinRT specifically. Central question I'm struggling with is: What is the best way to implement native C++ libraries (also by embedding them as a project in Visual Studio to provide native build experiences and dependency management on Windows) in your UWP application? C++/WinRT seems to heavily focus on WinRT-consumption (which makes sense, because this is what it is supposed to be!). C++/CX seems officially abandoned and deprecated and when you choose a Visual C++ library project in VS it automatically references VC++ libraries, which are anything but native and I'm fearing some kind of intermediate layer that gets in the way.
There must be some kind of industrial best practice for this scenario, no?
C++/WinRT and the older C++/CX language extensions are just ways to make Windows Runtime interfaces easier to work with from C++. One of the key design values of Windows Runtime is to make it easier to write a component that can be projected to C++, C#, and JavaScript.
If the purpose of your component is to be used by all those languages (which heavily influences the interface design), then there's value in creating Windows Runtime interfaces for your code. The clients of your component/library are free to use whatever method they want to consume your Windows Runtime types: C++/WinRT, C++/CX, C# or JavaScript interop.
As for the internal implementation, it's larger up to you. C++/WinRT supports authoring Windows Runtime components, and if you are looking for the "Modern C++" way to write Windows Runtime APIs, that's a good way to go if you are starting from scratch. You can also use C++/CX or the Windows Runtime Library (WRL) as well, although WRL requires some effort to keep the MDL generation in sync.
Walkthrough: Creating a Windows Runtime component in C++/CX, and calling it from JavaScript or C#
The Windows Runtime Library (WRL) (Channel 9)
If on the other hand you are just writing a C++ library that you expect to be consumed by C++ UWP applications, just create a Standard C++ library that C++ UWP or classic Win32 desktop apps can use (which I do in for example in DirectX Tool Kit). The only requirements this puts on your library is to stick within the Win32 API surface area available to UWP apps. See this blog series for various considerations here. In general, you can get it down to just a configuration flavor of your exiting code.
If you want to support both native C++ interfaces and Windows Runtime APIs for use by C#/JavaScript, you can then provide an optional component with native Windows Runtime APIs (like Win2D does for Direct2D/DirectWrite/WIC).
A little historical aside: WRL was the first solution for using Windows Runtime APIs from C++ but it was felt it was too difficult to use to author WinRT interfaces. Microsoft internal developers still used WRL for component development, but general developers were recommended to use the C++/CX path. See Inside the C++/CX Design. C++/CX heavily borrowed from existing 'reserved words' from Managed C++, which was less likely to conflict with existing code but also really confused people familiar with Managed C++.
C++/WinRT is a more modern solution that results in much more intuitive native C++ language projections of Windows Runtime types. The technology relies heavily on C++14/++17 language features which have been in development for some time, so it's really only been possible to fully implement the C++/WinRT solution recently. Consuming Windows Runtime async APIs in an intuitive native C++ way requires using co-routines which are in the C++20 draft. So overall, C++/WinRT is an elegant solution but requires cutting-edge compiler technology. See C++/WinRT