A bit off-topic. I don't know why, but I always thought that CefGlue was exposing hard to use C API. Now I see how wrong I was, I've looked at C<>C# generators in CefGlue and ChromiumFX projects and this is awesome!
I want that in cefpython as well.
Nowadays CefSharp done many steps forward, than the days when i'm touch it first time (in CEF1 era). It was actually very-very limited. Btw, CefSharp had been first .NET binding. But it was architecturally based on C++/CLI and needed other C runtime library, than default (nowadays it is not required, as i'm understand). So I'm started CefGlue just to try make "P/Invoke"-only bindings which can consume standard binaries, and as result it can be runned over mono on linux.
I'm always tried wrap CEF API into something other, but after using it in several projects, i'm found that way for me - is just stay close to CEF API (or having this possibility) works best for me. Anyway our applications always has own controlling layer, so involving additional API layers just no have sense. Probably, if we want provide ready-to-use embeddable control - API usually should be factored in other way, or peoples can't normally consume them, but - this is that i'm never done actually. And CefSharp's way of (re)organizing API in that case may be more reasonable.
And about C<>C# generators -> CefGlue always had partially hand-written code, and this is lot stupid code actually. ChromiumFX probably better, as it had been designed after CefGlue and design bit more optimal (i'm never look at ChromiumFX too deeply). Again CefGlue vNext should reduce amount of this hand-written code to about zero (except some core functions, like strings, list, etc). But there is still exist some code transformations which should be done: for example converting methods to properties (easy), or when C/C++ API has one ref parameter, sometimes in C# we should actually have only one return parameter (for example GetFrameIdentifiers() - it is more logical return array of identifiers, that accept reference to List which will be filled with ids).
So, i'm trying canonize this things and solve them in "complileric"-way, just for fun mainly, instead of ad-hoc writing cases. vNext will be backed by generated metadata from cef_parser + additional include parsers for internal types (done in C#, but easy can be rewritten to python), and C#-based generator. During initial development work are closed-source, i have plans publish public beta around CEF 59-60 releases.
Also i'm had some initiative with Marshall about providing standard XML-based metadata. Unfortunately this work has not been finished. And now i'm don't thing that it is very needed (rewriting internal CEF tooling without benefits - no have sense).
PS: If you want eventually want to discuss about bindings/generating - feel free to ask me (better exchange skype accounts in private messages).