Hi Alexandre. I've been researching similar things for years, and I've come to realize quite a few flaws in the current suite of available plugin APIs, some of which are reflected in your api as well, some of which I have yet to find a solution to.

For reference, this is what I use to develop my plugins, it's a managed wrapper for creating plugins in C#, and provides a bridge between VST and my interface, called SharpSoundDevice. I develop plugins for personal use, and my choice of C# is not up for debate here, I'm fully aware of its limitations :)

https://github.com/ValdemarOrn/SharpSoundDevice

To me, the biggest problems are:

1. Docking the UI inside the host. This is just an awful way to do things, as the host can intercept (and break) lots of event bindings in your UI. Notice how the scroll wheel and typing are broken in every other plugin in Ableton live? yeah, I mean that kind of stuff. Plugins should have its own window, but then of course, you end up with a problem where they should ideally always be on top of the DAW window, etc... This also means you have lots of platform dependent code for interfacing with the host. (I do my UIs in WPF these days, with some magic to dock the wpf panels inside the win32 window, it's ugly and I wish I could just handle it all inside my own application without worrying about docking windows within windows, etc. Solutions for developing plugin guis exist (like JUCE and VSTGUI, ugh), but it's a restriction on creativity and possibilities for developers (esp. for newcomers who are not familiar with how VST works). Wouldn't it be nice if we could just write "a desktop application", in Qt, WinForms, PyGTK or whatever, and it would just work? It can be done, but it requires someone to sit down and think. real. hard. which leads to my next point...

2. Process isolation... is hard.
Wouldn't things be nice if we could just run each plugin as a separate process. Well, you can, but you endure painful context switching. For multiple channels in parallel, it's not actually so bad, because all modern DAWs are multithreaded and can make use of the "lost time". The problem comes when you have 20 plugins in series, and each of them adds context switch latency of 10-15 uS, adding up to half the available time you have to process the buffer :) Still, some DAWS (like Bitwig) claim to run each plugin as an isolated process, I'm curious to know if they just say "fuck it, live with the added overhead", or if they have some magic solution to mitigate the issue.

I applaud the effort, but there is one more issue remaining:

3. Nobody is going to adopt your standard verbatim. Which means people will be creating wrappers, which means inheriting all the warts from VST/AAX/AU plugins. This is what annoys me most about my own interface. It's a relatively clean .NET interface, but I end up having to cover it in a layer of grit to stick it into a VST host :)

...yet I have not given up on building a universal, platform/gui independent, process-isolated plugin standard! Currently experimenting with named pipes and even Standard IO to define a common interface between host and plugin, which should allow running the gui in a separate process, and allowing you to write an audio plugin in any programming language that supports stdio... :)