I have no problems with, and see some of the utility of, reorganizing the API so that it sends info to separate writers for
- unconstrained parameters
- constrained parameters
- transformed parameters
- generated quantities
- sampler parameters
Getting the middle three separately will require rewriting the model class to allow each of those to be generated from the unconstrained parameters separately, and note that the immediately method of generating them independently will incur duplicated calculations that can be significant in some models (which is why they were all computed at once originally, no?).
In terms of implementation, however, I am not a fan of the proposal. Each of the above can, and in my opinion should, be abstracted to columnar data (naturally writable to data frames, dictionaries, CSV, etc) without any knowledge of what the algorithm or model will be spitting out. This abstraction will allow the same code to be applied to any algorithm (at the point where it emits a state) and will not have to be changed when the algorithms change.
I also think the algorithm configuration, adaptation, and timing info should be tackled in another issue as it requires a different architecture altogether, no matter how we do it.