I agree with you that roundtripping data in and out of Rhino with other formats can be improved. I think there is some misconception though about Rhino being “destructive.” You have to understand that Rhinoceros isn’t modifying the FBX/glTF/etc. file directly when you import it. Instead it converts the entire file to a format Rhinoceros can understand (the Rhino document [3dm]). Then when the export occurs it’s converting the entire Rhino document back to FBX/glTF/etc. There’s no link to the original imported file that can just be updated. A loose analogy is using Google Translate to go from English to something else and then back to English again. There’s bound to be some imperfections. Trying to get these imports and exports to match up as closely as possible is of course the goal. I readily admit the glTF exporter needs and improvement and I’m quite thankful for yours and others feedback.
PBR isn’t a standard but rather a set of techniques and ideas. The techniques create quite compelling results and as a consequence have been adopted widely. Because it’s not a hardline standard implementations vary, but since they all derive from the same foundational work they’re quite similar. This means interoperability is much closer than with other material definitions but may not be exact. glTF and Rhino are very similar but there are gaps. For example, glTF has no support for subsurface scattering either natively or through extensions. As a result I have nowhere to put that part of the material definition. There is some unavoidable loss.
I’ve kind of gone off the rails from glTF here but I understand where you’re coming from. I’d suggest making another thread about round tripping data with other file formats. It’d be very useful to have specific examples in specific formats about what changes and what you expect to be preserved. That way necessary changes or additions can be made.