I have been looking at this again, remaining / proposed changes:

• Rename C++ library so that to reduce confusion with source/eventHandler.py
  • Proposed name: WinEventCache
• Extract python code that registers for win events in source/IAccessibleHandler.py
  • Convert IAccessibleHandler into a package to group related files, and make backwards compat easier.
  • Proposed name: internalWinEventHandler.py
• Since the initial intention is to duplicate behavior, ensure any modifications to changed files since commit 4b53f8764 are captured as appropriate. 4b53f8764 was the master commit this was initially based on.
• Add an option in the Advanced panel to swap between threaded C++ event handler and python event handler
  • This may require NVDA to restart to take effect.

Decided on naming this WinEventCache since it's shorter, unique, and "threaded" is an implementation detail.

Would it be worht it to test this during daily use using a try build? Or is this still not mature enough?

@feerrenrut: thinking about this again, have you considered implementing the C++ code in this as a Python extension. I really understand that for historical reasons, the local NVDAHelper library was implemented as a stand alone library accessed using ctypes. However, now we are at Python 3.7 and no longer rely on old versions of VC++ to build extension modules, I think it should be considered, as the ctypes layer could be stripped.

have you considered implementing the C++ code in this as a Python extension.

I hadn't considered that. I'm not familiar with the ins and outs of python extensions. I don't think I would want to hold this work up further right now.

@feerrenrut What are you current plans with this pr? I'd love to see it going, together with a similar pr for the UIA event handling.

There aren't any plans for this. It was considered a risky change and hard to justify. To be able to prioritize the work on this, we need some reproducible test conditions to measure the impact this would have for users. After the initial work was done here, there were some significant changes made to the in-python eventLimiter (more detailed logging and more event filtering). This would need to be duplicated here, or a common abstraction would be required.

Due to the potential for regressions, the initial intention was for a period where both (in python, and external) event limiters were used.

I'm going to close this as abandoned.