I would also suggest moving to a compiled binary at some point. Very few Windows users are going to want to figure out Python in any capacity.
... honestly I don't know what. It makes zero sense - it's pissing off corporate users, who are already captive. I'm guessing hidden inflation strikes again - they can't afford maintaining two versions, so they prefer to go with the worse one.
This is only in regards to Office.
Yea, we're considering a .exe that people could download
Note: this is in the context of 'programmatically extending Office/M365', I don't think the OP was referring to COM in general.
COM is at the base of WinRT, which is pretty much _not_ deprecated.
If only they would improve the tooling, instead of like I am doing COM in Windows 95 with Visual C++ 5 kind of experience, because every time there is some project to improve the experience it gets killed after a while, and we're back to yet another C++ framework with the MIDL command line compiler.
(Though, going on recollection from past Q&As the excel devs have done, a more fundamental issue is that few people working they fully understand how COM works, and they are getting fewer)
The app itself (Outlook) dropping COM support is simply given it no longer needs COM support for add-ins, it can drop COM itself.
Microsoft is kinda-sorta pushing for machines that can do AI stuff locally with their copilot branded PCs, but I don't see any evidence that they are willing to go all in on AI powered locally controlled everything with no SaSS model attached.
There is an open issue in OpenAdapt to implement COM support: https://github.com/OpenAdaptAI/OpenAdapt/issues/873
This could be a valuable reference.
Let me know if you are interested in turning this into a startup, happy to direct you to some relevant people.