UWP limitations in desktop apps
I know that the new UWP app model has some limitations when comparing to "traditional" Win32 apps.
Let's take Visual Studio Code as an example of a desktop app.
What features of Visual Studio Code were missing or had to be different from user perspective, if it was an UWP app?
EDIT: I've done exams for microsoft certification "Essentials of Developing Windows Store Apps Using C#" and Exam 70-355: Universal Windows Platform – App Data, Services, and Coding Patterns. So I know something about win rt api.
Please don't bother with answers like "uwp app runs in sandbox". They are useless, because they say nothing about the limitations from users' perspective. I intentionally took real life example, so we can go concrete.
The limitation could be, that your app cannot support 3rd party plugins like custom syntax highlighter or refactorin extension(it was limitation of windows store apps, not sure if its still valid).
Another limitation could be, that your app is not able to take screenshot, because there is no api in uwp for it (not sure it its true, actually)
Answer
The phrase "Win32 desktop app" is a ill-defined since the Win32 API programming model has been around since Windows NT 3.1. It can also cover dozens of development languages and UI frameworks over the intervening two decades.
Here's a quick overview of the key UWP differences:
API surface area. The UWP platform supports many but not all Win32 and COM APIs, and introduces new APIs. If your "Win32 desktop app" is using mostly ANSI APIs that date back to Windows 95, then you have a lot of updating to do. If you are using mostly Windows Vista era UNICODE APIs, then a lot of stuff "just works". See Win32 and COM API for Windows Runtime apps (System).
Security context. The UWP platform runs applications in an AppContainer security context. "Win32 desktop apps" on Windows Vista or later run as "Standard User" or as "Administrator". UWP apps have less access rights than "Standard User" and can never run as "Administrator". UWP apps can request additional capabilities to get a few more rights with permission from the user, but have limited access to the system and user data. For example, you cannot read most of the filesystem, only your installed location, an isolated application data folder, and an isolated temporary file folder. See File access and permissions (Windows Runtime apps). This also means UWP apps have limited access to devices. See Device and sensor overviews.
Windows Vista User Account Control that introduced Standard User was focused on protecting the system and other users data compared to the older "everything is administrator" model, but did little to protect the current user's data files since all apps could access or even modify it. AppContainer isolation is protecting both the system and the current user's data and settings. "Win32 desktop apps" were encouraged to install to
C:\Program Fileswhich was read-only at runtime and to use application data folders, but they were not required to.
AppX deployment. "Win32 desktop apps" use any number of ways of deployment, often something using MSI technology and running as "Administrator". UWP apps are packaged in AppX files and are always deployed by the system. There is no "Custom Install Step", and therefore UWP apps cannot install drivers or services, change ACLs, etc. The system takes care of deploying the C/C++ Runtime (which must be Visual C++ 2015 only).
UI model. There is a plethora of UI frameworks for "Win32 desktop apps" like WinForms, MFC, WPF, etc. The vast majority of these are not compatible with UWP because UWP does not support classic Win32 windowing,
WM_messages, or GDI/GDI+. For UWP apps, you can use XAML with C++ or C# code-behind, DirectX (Direct2D and/or Direct3D) with C++ (or C# via 3rd party assemblies like SharpDX), or HTML5 with JavaScript.
Answering your question is therefore extremely difficult, if not impossible, without a complete understanding of the product's code base and dependencies.