@vilters I absolutely concur on the complexity of the code. I've been working for quite a while on Python code which replicates as much of the library pose loading and saving functionality that the Python API supports. Accounting for all the possibilities of transform channel names, from the earliest, language-configurable resource references, to multi-byte character sets, and still allow a pose to be applied as intended, is fiendishly complicated. All those development decisions which have accumulated over time, either to maintain compatibility, or leverage a new possibility for functional expansion, that weren't envisioned when the file formats were first developed (and to my knowledge, the complete file format definitions have NEVER been officially published, only reverse engineered by enthusiasts) inevitably result in complex code.
Even Poser's propensity for saving scene files which significantly differ from the scene loaded, despite no changes being made in the UI before saving, seems unnecessarily obfuscatory. (Just look at the order of hidden joint parameters in a figure, which seem to get reversed every time the scene or character is saved and loaded). But, presumably, that mode of operation arose at a time when Poser's internals did not give different results if the evaluation order of joint and other parameters were re-ordered, so it didn't matter then.
Such functional oddities, which don't generally impact perceptibly on Poser's usability, except in edge cases (which are the ones I frequently run into) have an understandable tendency to linger in the code base, inevitably complicating efforts to streamline and refactor code when a core rewrite becomes necessary to implement some new, performance or functionality boosting feature.
