I think it comes down more to the question of adding parts of add-ons rather than the entire add-on. Because add-ons derive their power from NVDA Core, it comes down to looking for changes between NvDA and add-ons themselves.
This task isn't easy for at least three reasons:
- As mentioned numerous times, the ability for an add-on to get itself running on recent NVDA releases depends on the attitude of add-on authors themselves. If authors are willing to keep up based on documentation from NvDA (namely what's new document and code samples coming from others in the development community), then add-ons will be updated.
- Different authors use different ways to express code. Although Zen of Python advises folks to strive for one solution, there are different ways to do things. For example, people can go through a list of records using either a for loop or a while loop, or if one gets into advanced mode, perhaps using container comprehensions (comprehensions come from functional programming; way advanced for the scope of this list, I'm afraid). There is a common coding standard NVDA contributors are expected to follow (such as using tabs to denote indentations), but not all add-on authors use this style (if they did, it will make life a lot easier, but folks have different ways to express themselves, and I think that should be respected).
- Add-ons patch things here and there. In some cases, add-ons would come with their own implementation of a core NVDA feature or two (the best known example is Remote Support add-on). If an add-on patches an NVDA feature or two that other add-ons rely on, it creates a situation where other add-ons you've got may not work properly. Although folks may think patching NVDA Core may help in getting add-on code to resemble NVDA code, it does not - rather, it makes it difficult to separate the differences between what is core versus add-on. For this reason, whenever I need to override some NvDA functionality, I always include a comment that helps me remember that I need to look for ways to not disturb other add-ons (Windows App Essentials is a good example of an add-on with such comments) and do my best to call NVDA feature itself in the end.
Here is a list of parts of add-ons that ended up in NVDA itself as far as I know (spoiler: this list includes current NVDA alpha builds):
- Screen Curtain: originally devleoped by Leonard de Ruijter (formerly of Babbage), I packaged it into an add-on, knowing that NV Access, too was thinking about incorporating this feature into NVDA in the end. After months of public testing, it did become part of NVDA 2019.3.
- Enhanced Aria: originally developed by Jose Manuel Delicado, the ARIA article landmark constatn became part of NVDA 2019.3.
- Focus Highlight: originally developed by Takuya Nishimoto, most of its features (now known as Visual Highlight) became part of NVDA 2019.3.
- Enhanced Touch Gestures: the following parts of my add-on became part of NVDA in recent releases: toggling touch support, mouse right click touch gesture (one finger tap and hold), and touch typing mode where you can toggle between lifting your finger or a double-tap to enter text via touch keyboard.
- OCR: a different implementation is used on Windows 10 and 11 that has nothing to do with the recognition engine that originally shipped with the original add-on (OCR add-ons was originally developed by NV Access).
- NV Speech Player: although not part of NvDA directly, the Edward voice is part of eSpeak NG that ships with NVDA 2021.1 (if I remember correctly).
- Resource Monitor: I noted a few days ago that parts of at least two add-ons will be part of future NVDA releases, and one of them is Resource Monitor. Specifically, Windows release information internals is now part of NVDA (as of alpha builds), and for those reading NVDA source code, NVDA now has the ability to detect which Windows 10 or 11 release you are using via Windows Registry (this part came from Resource Monitor).
- Windows oneCore voices: formerly known as Microsoft Mobile voices, this synthesizer was originally an add-on (developed by Tyler Spivey) before making its way to NVDA.
- Windows App Essentials: over the years, many parts of this add-on (from me) were included in NVDA. These include modern keyboard facility (emoji panel/clipboard history/dictation/voice typing/hardware keyboard suggestions), announcing search suggestions if present, UIA notification event support, and countless small things here and there. In fact, parts of the add-on made their way to recent NVDA alpha snapshots, including Windows 11 detection and support.
- Add-on Updater? Maybe... (behind the veil at this time)
As for the procedure I use in add-on development: I keep a close eye on changes in alpha and beta releases, and to some extent, NVDA pull requests that are being worked on by NV Access and contributors (including my own). As a result, at least for Windows App Essentials, it contains code that responds to latest NvDA alpha snapshots, including the next big thing for add-on authors to consider: control types refactor (I won't go into this change, but suffice to say that control types refactor (involving a syntax change) will affect many add-ons, and I have advised add-on authors to prepare their add-ons).
Hope this helps.