> not touching anything remotely related to Microsoft, even if it's a properly licensed open source, is way better and even some GNU projects have no issue with it.

For sure those are important but what actually drivers a project are accepted COMMITS and GOVERNANCE. If Microsoft puts the right license sure anybody can fork it if somehow the project goes in the wrong direction... but if most contributors are Microsoft employees doing those commits, or refusing others, what will happen? The license or how "better" the project is won't help. If KDE does not trust Microsoft (one of the largest corporations who is selling proprietary software since its inception and still do this day) then even if the "better" solution is from Microsoft then strategically KDE is right to avoid it.

You're not wrong, but even then forking a well established, well designed and not anti-pattern-ridden project with a massive library of build recipes for your own purposes is still better than maintaining some bespoke code used by two projects that forces developers to go mad, give up and quit.

My point was maybe not articulated well: it wouldn't have to be vcpkg. Could be Conan or something else, as long as it's not making you waste your free time and actually help producing reproducible builds and distributables on each platform supported (Linux, BSD, Mac, Windows).

To put this in perspective: KDE is in this situation Qt, they were lucky to negotiate a good contract to keep Qt licensed to KDE favorably, and most importantly, open source on their terms.

Without that deal, KDE would be at Qt's behest as they changed licensing, pricing, etc over time.

Getting into that situation again with Microsoft as a non-profit would be foolish.