I've been "on the other side," part of a big corporation forking an open-source project. In Laine's case, what I would suggest is to focus more on what Microsoft added and changed; try to understand why they did that; and see if you can get any value bringing it back into your project.
(IE, don't let your ego run away.)
Why?
In my case, I was working for an industry-leading product that required a bit of reverse-engineering into MacOS. We got stuck on a new release of MacOS, so we did a bit of digging and found an open-source project that successfully reverse-engineered what we were trying to do.
(Basically, integrating in the right-click menu in Finder required reverse engineering prior to 2014; and every version of MacOS required redoing the reverse engineering.)
It was a legal grey area to copy how the open-source project reverse engineered MacOS, so I reached out to the open-source project and tried to collaborate. We exchanged a few emails and then I found a problem...
Basically, their solution had rather large memory consumption in Finder if the user had very large folders. Our customers had very large folders. (Edit, 200,000+ files were common.) We still wanted to collaborate, so I proposed a fix that fixed the problem.
But, then "radio silence" from the original authors. We forked and complied with the license. I always hoped they never begrudged us.
(Ultimately, Apple released an API so we didn't have to reverse engineer MacOS.)