Midgard2 entered LTS state, so Midgard developers focused on Midgard3 architecture design. Among others, main goals of Midgard3 are: extended traditional (ORM like) database storage routines, contextual workspaces similar to (very smart) virtual databases, compatibility with RDF and triplestores.
New, proposed API is quite simple and flexible, with many ideas, many developers working with content data are familiar with. Also, new API is not as much limited as Midgard2 one. Though the latter is (very much) suitable for desktop, mobile or web applications. Needless to say, Midgard2 is (probably) the only one GObject based library, for which, PHP extension exists, serving gazilion websites every single day.
In new architecture, we decided, to change the whole API, while keeping implementation code mostly untouched. As much as it's possible.
So, when we started to write new API in vala, the idea was born to share exisitng C code with the one generated by valac.
In other words, API is written in vala, while implementation is taken from existing code.
Today, I commited all important changes to our git repository, creating three different libraries: legacy, core and vala based. Also as first initial test I removed MidgardConfig sources from legacy API, implementing it in vala. And, as a result, legacy public API uses the same class written in vala with actual implementation done in internal core API written in C. Development speed is not the only one benefit. Another one for example is fact that legacy API implementation might be changed to new routines, keeping separate APIs in safe state, while providing more predictable solutions for developers.
Last but not least. Big thanks! to juergbi and Lethalman for their help on #vala channel.