I do not know exactly all details in bayesplot. I think it depends on how we regard bayesplot. If we regard bayesplot as a generic package for plotting “bayes” stuff, and plotting rstan posteriors is one instance of the generic posterior plotting, then baysplot should not depend on rstan imho. If I would like to use JAGS or Tensorflow with bayesplot, I would not like to have a rstan dependency. rstan should then be one instance of a generic baysplot and rstan specific handling (such as bayesplot::nuts_params) should be implemented in rstan, where the “constructor” exists. This is how I assumed the intention of bayesplot.
Although, if baysplot is rather a “rstanplot” package, i.e. bayesplot only have functionality for plotting rstan objects. Then I think it should only depend on rstan, and rstan should be able to ignore bayesplot all together (i.e. bayesplot should be at the level of, or just, below rstanarm and brms).
Since I do not know bayesplot, it is maybe both, and we dont want to litter rstan with plotting functionality. Then I think it would be good, in the long run, to refactor the package to two packages, one with generic bayesplotting functionality (that could be use with any framework) and one package specific for plotting rstan objects.
The important think for me when developing is to know what to do to not break things. Ideally, if I develop in loo, and as long as I do not change the loo API nothing should break higher up in the dependency levels. Also, I should not have to care about any higher order dependency or package. This also good since I probably dont know these internals very well. If I work loo, I should not (in loo) need to care about the brms implementation of loo, that is something that should be done in brms.
Im not sure if this made it more or less clear. This is of course not in a hurry, but getting a decision in place will simplify implementations for me.