I’d prefer not to try to do this via discord; the bandwidth is too low unless synchronous.
As far as collaboration goes, my philosophy of plugins is that as much as possible, they should be small and aimed at synergy with other plugins rather than taking on all possible aspects of a task, especially if it results in a lot of UX choices that different people may not agree on.
This is especially true when dealing with something like folder notes, where the underlying thing is really a convention or agreement of structuring things in a vault, but the specifics of how people want to work with them is different. When plugins combine core functionality with UX extensions in the same plugin, it makes it harder for end users to mix and match features.
My kind of philosophy for plugins related to folder notes is more similar to how Calendar, Periodic Notes, Natural Dates, etc. work together: there is a core plugin (Periodic Notes) that provides configuration and an API for working with it, there are UI plugins you can take or leave, and then other plugins that optionally integrate with that ecosystem.
In the folder note space, it would be nice to have a folder note plugin with slightly more functionality than NFA does right now, with configuration and an API, and file-menu operators for the basic creation and automove/rename of folder notes. Rather than doing any templating, it would instead fire an event to notify other plugins of a folder note being created, allowing them to provide or alter the text. Rather than manipulating the built-in file explorer, it would provide a utility API to get the note (if any) for a folder, or the target path for creating one, so that file explorer extensions don’t have to duplicate configuration and code.
Then, other plugins can exist to change how the builtin explorer works, to provide templates or fancy views, and of course other plugins can use it to provide special features the way Quick Explorer does. Plugins that want to do things involving folder notes would just defer to and depend on this central plugin rather than duplicating the functionality in a mutually incompatible way with one another.
In this way, user choice and plugin flexibility is massively increased, because people can pick and choose the pieces of their solution. For example, templater plus dataview to create default folder notes, and so on, or different approaches to integrating with the file explorer.
My current plan was to create a successor to NFA, Folder Note Manager, with the above core functionality, an npm API, and a way to access that API from other plugins that doesn’t depend on accessing Obsidian’s internal plugin structures or redeclaring types. The specific functionality would be to do what NFA does, but with a choice of folder note strategies, and the option to do bidirectional autorename, not just the unidirectional it does now. There would be another command to unmake a folder note, a folder context menu item to create a folder note (with an event hook for templates or macros), and a file context menu item to turn a note into a folder.
The main reason I was thinking of doing this is that I want Quick Explorer to support creating folder notes, but it’s currently using a hardcoded strategy and I really don’t want to end up with a monolithic thing that forces one strategy or competes with other choices in this area. So my thought is that by making FNM (folder note manager) to implement a mostly-UX-choices-free system for managing folder notes, then QE and other plugins can build on top of that.
. So I’ll create a parallel project like 
If I figure that out, then I might be able to come up with a way to define other virtual paths for the breadcrumbs, and thus support your breadcrumb model, whatever that is.
