The answer to that question is a lot less obvious than one would expect.
Windows installation upgrades (hereafter "migration") have been blocking setup if a known-incompatible program[1] is detected during installation, telling the user to uninstall it prior to allowing the upgrade to continue.
For Windows 10, the goal was to make the migration process (which would take ~40 hours to gather/apply on a typical system from Vista -> 7, the same process takes 20 minutes to an hour on upgrades to modern 10 nowadays) a lot faster, and a lot more seamless, as to get as many users as possible on the latest OS release to reduce effort supporting other software versions[2] and such.
Of course, blocking the installation with a known-incompatible program would result in popping up to the user, say, 'hi, this update can't install until you uninstall this program. please do so!', and they of course will respond 'what update? I don't want to uninstall my program so you can install an update! [I don't trust this at all/I'll forget/...]', and therefore said update (which wouldn't just be from 7/8 -> 10, but also cross-build on 10 itself) would never get installed.
There is no sane way to ask the user, since this will reduce adoption of new builds further than what people not understanding/accepting Microsoft's POV on this will attempt by 'not upgrading'.
[1] A common case to cite is the deinstallation of the product 'Speccy', which, funnily, will cause a system crash in a kernel driver shipped with the product if said older version is later installed on the new OS version and run. Given the chance people will have odd ways to automatically start this, and that people's systems will instantly crash if run, it makes sense to block the installation on this product.
[2] I maintained a hobby product that worked with fringe cases in the OS for a long period of time, and over time as I moved to newer OS versions myself, I'd end up having a large amount of features break on downlevel systems due to depending on new implementations/refactors done in 8, 8.1 or 10 with regards to those components of the OS.
That's an "interesting" approach. Unfortunately, it is made worst by the fact MS laid off tons of testing engineers a few years ago, and now release clearly buggy versions of Windows. To add insult to the injury, it now does so (adding new bugs and new incompatibilities with perfectly fine programs) every few months...
Windows installation upgrades (hereafter "migration") have been blocking setup if a known-incompatible program[1] is detected during installation, telling the user to uninstall it prior to allowing the upgrade to continue.
For Windows 10, the goal was to make the migration process (which would take ~40 hours to gather/apply on a typical system from Vista -> 7, the same process takes 20 minutes to an hour on upgrades to modern 10 nowadays) a lot faster, and a lot more seamless, as to get as many users as possible on the latest OS release to reduce effort supporting other software versions[2] and such.
Of course, blocking the installation with a known-incompatible program would result in popping up to the user, say, 'hi, this update can't install until you uninstall this program. please do so!', and they of course will respond 'what update? I don't want to uninstall my program so you can install an update! [I don't trust this at all/I'll forget/...]', and therefore said update (which wouldn't just be from 7/8 -> 10, but also cross-build on 10 itself) would never get installed.
There is no sane way to ask the user, since this will reduce adoption of new builds further than what people not understanding/accepting Microsoft's POV on this will attempt by 'not upgrading'.
[1] A common case to cite is the deinstallation of the product 'Speccy', which, funnily, will cause a system crash in a kernel driver shipped with the product if said older version is later installed on the new OS version and run. Given the chance people will have odd ways to automatically start this, and that people's systems will instantly crash if run, it makes sense to block the installation on this product. [2] I maintained a hobby product that worked with fringe cases in the OS for a long period of time, and over time as I moved to newer OS versions myself, I'd end up having a large amount of features break on downlevel systems due to depending on new implementations/refactors done in 8, 8.1 or 10 with regards to those components of the OS.