There is definitely a lack of plugins available for Able. And I don't see many outside developers offering ones.

I came over to Able from twenty years of using OsCommerce. It was an open source project and had a strong public support.
There were many addons and help was easily found in the forum section if you had an issue.

Unfortunately, OSC went several years without a viable update to the core code, mainly due to its sale to a private group in Europe.

I would love to see more plugins offered to expand the power of this great software.

That is unfortunate. I spent several hours last night finally getting a plugin to build, zip, and install to the website.

However, maybe it is a small blessing in disguise. It was painful to get the plugin up and running because of library differences between the Random Quote samples and 9.0.6. Was also thinking about what it would look like if AbleCommerce updates controller logic and/or view templates that we basically copy+paste into Plugin projects... We'd have to run merge comparisons between their code and our plugin code after each update and hope we covered everything. However, if we put our changes into the main project, Git will show us all of the changes generated by the update so we should know what needs to be merged.

Like you mentioned, I can see it being useful for completely new features and widgets.

And there in lies the real issue with the idea of copying existing Able behaviors. Now your merge workload just increased by a very large amount.

There are customization design standards that can help with this concern, but not completely eliminate it.

For example:
I always put all new behaviors in separate controller files and views. I never just add them to the existing controller file. I modify the original controller as 'partial' and just create a new file in a /Controllers/Custom/ folder. This isolates all new behavior customizations quite nicely when it comes time to install an update.

In full source, I do the same thing isolating my custom work via partial and starting a new class file in a /Custom/ folder.

When it is necessary to modify existing behavior and views, I denote those changes at the beginning and end with comments in both controller and view files. This plays well when using a tool like BeyondCompare to merge the upgrade files into my modified ones. My changes now stick out like a sore thumb to the compare tool. This doesn't eliminate the merge work, but greatly speeds up the process.

Certain occasions require massive modification to a specific view (ex: category page). In those cases, I'll copy the entire Able view to a /Custom/ file and just change the filename in the original controller's return PartialView("_whatever.cshtml") to PartialView("/Views/Custom/_whatever.cshtml"). This way I've minimized merge-change work for the next update and I'm not trying to compare a 1-line change made by Able to a view that's been completely rewritten by me. The vast majority of Able's view changes don't break a previous copy of the view. Not a 100% guarantee, I've had a few problems in the past. But overall this saves a ton of time.

Table/schema changes are the least flexible. All those mappings are in nHibernate and there's no way to change that with a plugin. You could extend the object class, but that still doesn't update the nHibernate mapping file. I've never understand why Able hasn't switched to fluent nHibnerate mappings...maybe there's a technical reason I don't understand. These xml mapping files are just barbarian. And fluent mappings could be overridden, so far as I know. But then you get into a situation where multiple plugins override the same object class and things get ugly fast.

Using the custom-fields classes work, but only to a point. While beneficial for basic read-write of field data, they become terribly awkward and cumbersome when you need to search or report those custom fields.

Merge is a pain but you can minimize that pain quite a bit with consistent customization standards.