I am not sure we need a common convention, as conversions should be trivial. Also
I would rather have the user convert between log and linear values when applicable. TBH, for MCMC a non-log PDF just does not make sense numerically and is not something one can recover from with a simple log as most of the precision is already lost to under/overflow.
If anything, I would not stick to a NamedTuple, just support for getproperty or accessor functions as @ChrisRackauckas suggested.
As for auxiliary/incidental computations, it is kind of tricky to decide what should be done with them, or if they are needed. Keeping eg 1024 of them around for a NUTS tree of depth 10 may be excessive — I would rather allow them to be calculated on demand with a closure, similarly to how Zygote does backtracing.
For my own packages, related discussion was in
I am planning to redesign the API soon, in a single breaking change.