tl;dr.
API incompatible but I hope a search-replace can fix most of the compiler errors :D. And we will replace XML with JSON, nicer format.

Well, the API will be incompatible to liblcf because there are some design issue that must be resolved which make the code unflexible. Planned changes: The ldb_/lmu_/lmt_/lsd_*.cpp files in generated-folder will probably dissapear (but that wasn't public api anyway, just template-voodoo). Most of the unreadable template code (reader_struct) will be gone \o/. Everybody hates it, on devices like the raspberry the compiler even runs out-of-memory >.<.
Currently it's e.g. almost impossible to provide a XML (or JSON) file that only contains one RPG::Actor and parse this with liblcf (we will need this for the editor, for import/export/copy/paste). And this will also make the editor-project-format more version control friendly when all actors are e.g. in a seperate file (will be merged in one file for deployment).
I already got a first version of this working yesterday, so you can do std::unique_ptr<RPG::Actor> actor = RPG::Create<RPG::Actor>(json_string); in vNext +1.

Public API: All the RPG-classes will stay but instead of public members it will be with Getter/Setter so instead of "std::string title" you have GetTitle/SetTitle (and for Vector just a const&non-const reference-Get obviously). So to become API-compatible again we will need a gigantic search/replace in Player & Editor.
The RPG-classes will be JSON-backed [rapidjson] (more an idea, need to measure memory and performance first though, Heros Realm is a good candidate :D), this gives more flexibility (custom values, when we extend the event script language e.g.). Though that's abstracted away by the Get/Set functions, the user of liblcf can ignore it.

I will change the inheritance, because currently it's e.g. not possible to add convenience functions to RPG::Actor because it's generated (e.g. GetClass() would be useful, current code does Data::classes[actor->class_id - 1] and that's without the out-of-bounds check, ugly code, results in errors). And Data::classes is not even the most awful, some code (especially battle code) has 3 array-lookups :D. And currently all that logic is in Player, but would be useful in liblcf, too (for editor).