How do I add custom built plugins - Lot's of confusion

I understand if you're confused, we could probably use some help with documenting how custom plugins are supposed to be connected with the editor through Wysiwyg's API. The fundamental issue is that the available features in editor libraries or their plugins are pretty much a black box for the serverside code unless there's an easy way to inspect the library files to check if something is there or not. But to do that, you need to know what to look for.

The CKEditor builder poses a bit of a problem for us, since we need metadata about each plugin (its internal name, and the internal names of all buttons it has, and their corresponding "human names" to be shown in the GUI) before the checkboxes in the profile configuration GUI can be generated.

Modules can implement hook_wysiwyg_plugin() (see wysiwyg.api.php) to give Wysiwyg module metadata for any plugin it doesn't already know to look for. Without that information we can't show any other checkboxes because we simply don't know if they're there or not.

I've made a couple of attempts at automatically scanning the editor folders for this information, but without actually running all files through a JavaScript engine, performing a deep analysis of the data structures, and finally extracting the values from there, we'd be lucky to successfully detect half of the available buttons. Even then we'd not always get the human readable names of buttons/plugins since they're not always included in the source, depending on the editor.
I believe the standalone CKEditor module does make an attempt to parse some code and find some of the metadata, but they only have one editor to focus on, and I think it misses a lot of cases.

If you're concerned about upgrading to D8 later, I don't think it'll matter which module you go with. There won't be an in-place upgrade path in the traditional sense from D6 or 7 to D8, but a migration. That migration will take your existing content and metadata about it (like the selected format) and put in into a new D8 site. As D8 has a much deeper editor integration than we can ever get with D7, there's not always an obvious mapping between settings and functionality that could be automated by either module. That, of course, doesn't mean I won't look into how that'll work and see if there's something I can do to make the transition easier - I will after all port Wysiwyg's core to D8, though I'm not sure there's a need to port the CKEditor integration itself because of the existing integration in D8.

I don't have time to write more right now, but if something is unclear I won't mind continuing later.

Yes, CKEditor has a very good API, but it's all clientside in JavaScript so we can't use any of it while building the GUIs or settings objects on the server. :(

We'll probably get around to have Wysiwyg automatically detect native editor plugins at some point, but until then we'll have to do with declaring plugin metadata in hook_wysiwyg_plugin(). Too many other things to fix before expanding to such tasks.
(If anyone wants to try, a 3rd party module could implement that hook and do the scanning on behalf of Wysiwyg, as a module can present more than one plugin at a time.)