Ugh. The exporter checks for "valid" chars in the group name, but ignores the whole string if there is a single invalid char. Instead you end up with a number (i++) as the group name. Of course this breaks lots of things if the naming is part of a hinge/rail that gets reimported.

Nothing wrong with the exporter checking for valid chars, I wouldn't have programmed it any other way if I had to do it. It's essential that you can rely on exporting an object that is not corrupted by invalid naming.

It's a shame we only have the option to do this export/import malarky using the prehistoric obj format.

Prehistoric? Hardly.
Just try to implement the hinges/rails in any other format and have them retained when exchanging the object between Sweethome3D and Blender.
It's open source, very generic, widely supported, and in a plain text format which allows easy editing. For software like Sweethome3D it's an almost perfect format. The only thing is that only a relatively small set of the features is implemented in Sweethome3D through it's user interface and export/import. For example the d for transparency and Ni for optical density (glass refraction!) properties should be made available through the user interface just like shininess.