Hi Arafat,
sorry for the late reply.
Looking through the proposal, it certainly looks like you've picked a pretty cool, but rather ambitious task.
From a maintainability perspective, I doubt that building a Ruby API on top of matplotlib-cpp is the way to go.
The reason being that being that when I started working on this, I was already way behind on my thesis deadline, so I needed something that produced results *asap* and was easy to use. Good software engineering never was a consideration. That's why the library embeds an actual python interpreter, requires a global lock for all function calls, and prevents all other uses of python within the same process. (it's also the reason why i'm hesitant to add 'proper' CMake support, I don't really want it to resemble a conventional library too much)
So, if you decided to build a Ruby API on top of that, you would end up with a ruby library that internally starts a python interpreter *and* would prevent other applications from linking against both your library and another python library. It seems to me like that would be a rather obscure architecture, and would in the long-term lead to lots of frustration over hard-to-find bugs.
Instead, since you seem to be willing to invest some time in a proper solution, I would suggest to go with the alternative that you discarded in your proposal and try to fork the C core of matplotlib, expose the functions contained in it and re-build the python part in C as far as practicable, with a new ruby library on top of that.
This way, since a C library would be usable from any other language, the core part could be useful to a wider set of people than just ruby developers and would therefore be able to get more interest and contributions. It also opens up some desirably features, in particluar proper multi-threading support, that are plain impossible to add when building on top of python.