LOL, yes it is complex and hard to wrap my head around, and so I’m doing my best to process it all – with smoke frequently coming out of my ears! I very much appreciate all the help and insight you have provided! 
Continuing further: while it is best to use raw photos that have been processed into scene linear, if using online resources of unknown processing origin intended to be used as textures, it can be useful to apply a curve that reduces the contrast a bit, attempting to remove the tone curve on the image (imperfectly of course since the exact curve is unknown). Here a good choice for this image pre-processing is the ACR curve. Thus the image is pre-processed, then input as utility-sRGB-texture to linearlize it.
This method addresses the issue of sRGB images having crushed blacks, and is preferable to the older method from Cinematic Color 1 of using an inverse of the display transform (rather than utility-sRGB-texture) as the input color space that is made not to have values above 1, because…
“if you were to apply a random inverse tonemapping function to them you could break them.” By “break them” do you simply mean that this “needs to be done with discernment” as what looks good for one image may not for the next, and so one would in the new method (pre-processing with ACR) be able to discern that the image looks bad when reading it into Mari, and correct it there as needed, whereas in the old method (using an inverse tone curve below 1 as the color space) one would not have the opportunity to fix errors/yuckiness in the resulting texture and its effect on the render as it is simply being assumed that everything is fine with the resulting texture and its effect on the render.
Assuming that I got the above correct, could you expound a bit on the possible effect on the render that a texture with an inverse tone curve could cause (again assuming it has a matrix to make it not go above 1)? I’d like to get a better understanding of this and it’s impact on PBR so I can communicate this to my students. 
You mentioned elsewhere something about injecting non-linearity in the rendering system and thus biasing the light transport equation. Would that be the case here with the older method of using the inverse of the display which does not go above 1? If so, could you elaborate a bit on “biasing the light transport equation” and what that means in layman’s terms?
Hey @nick, speaking of cinematic color I, I saw that you have Cinematic Color II up on Github. However the images are not appearing (just the reference to them in the text). Is there a version up some where with images?
I will try to go back to your previous questions later but answering this one specifically: CC2 is not published yet, anything you see online here and there is transient and not final.