First is that the different folders came from early refactoring efforts that were originally focused on doing an all-at-once conversion to C++. We probably just want to do things carefully in regards to change history, tracking, etc. but I believe the latter folder is now the preferred destination.

Also, take care on what widgets you are looking at. We have a few groupings in our source tree that are meant to stay C (due to being libraries copied in-tree, code meant for reuse with other projects, etc.). For those the preferred approach would be to keep core functionality in C-compatible files and provide C++ wrappers with Gtkmm. (this is also how Gtkmm itself is written)

*HOWEVER* do be careful about low-level and/or wrapping issues with Gtkmm. If the behavior is added only at the C++/Gtkmm level, some widgets misbehave when interacting with Gtk. The 'native' Gtk object held by Gtkmm class instances may sometimes be passed to C API's of Gtk or other classes. This is especially common with some of the data APIs such as trees, UI lists, etc. In those cases C++ methods don't get invoked, object slicing might occur, etc.

A safe way to mitigate many of the C vs C++ issues with Gtkmm is to keep a proper logical separation between Gtkmm UI objects and the functionality they trigger or state they manifest. The bulk of code ends up in plain C++ classes, while the Gtkmm widgets merely provide a thin layer to expose them. Conceptually this is easy to visualize for the case where Inkscape is invoked from the command-line on a system that doesn't even have a display. In that case all functionality will work (via command-line params, scripting, DBUS, etc) even though no widgets should even get instantiated.