Is your feature request related to a problem? Please describe.

For many applications, we have to support many different versions. Most important and major examples of this are Microsoft Outlook and Microsoft Visual Studio. The outlook appModule, for example, contains very old code of which it is yet unknown whether it can be removed or not. If new code is introduced, it is hard to know whether it will break support for older versions of the application.

Additionally, applications like skype and poedit got entire rewrites.

Describe the solution you'd like

I think that using overlay/mixin classes for version specific functionality can solve this problem. This allows for much flexibility, i.e. you can provide generic functionality in the base appModule and add version specific workarounds in an overlay. I know that @JulienCochuyt ported the overlay classes support for NVDAObjects to the textInfos system as part of the WebAccess add-on. It should be possible to come up with an approach that is more general to AutoPropertyObject.

Describe alternatives you've considered

I think there are several alternatives to make it possible for an appModule to be version specific:

• A separate module per version or version range. This makes it more difficult to share or override code, though
• Bundling Appmodule subclasses for multiple versions in one python module / package.

Additional context

JAWS introduced support for app version specific scripts pretty recently. Dolphin SUpernova has this for ages. It's not that we should blindly copy others, but it looks like the others have seen shortcomings in a system where one module has to support multiple versions of an app.