Just throwing a couple of thoughts into the mix (and I realise it’s probably a bit late, because I missed a few VWG meetings).
I vote for the removal of “moncurveFwdMirror” and “moncurveRevMirror”. They seem redundant.
Is “moncurve” a confusing name? I assume that is an abbreviation of “monitor curve”, and the Rec. 709 curve is absolutely not a monitor curve (EOTF); it is an OETF. The sRGB curve is a monitor curve, but as specified currently the “moncurveRev” style needs to be used to implement the sRGB EOTF. This is a bit counterintuitive. Logically the forward form of a monitor curve should be the EOTF, should it not?
On the subject of sRGB, the example given states that it applies “the EOTF found in IEC 61966-2-1:1999 (sRGB)”. This is not strictly true. It produces an idealised form of the sRGB EOTF, where the tangent at the break point is an exact match for the linear portion. This is not exactly the case with the rounded constants given in the standard. It is not possible to exactly replicate the sRGB curve from the IEC standard using the moncurve formula. Whether this actually matters is a different question!
I have not investigated, but I suspect that the same may be the case for some camera log curves.
Lastly, for ease of understandability, might it be easier to use the same calculation of s for moncurveFwd and moncurveRev, and just use moncurveFwd(x) = x * s and moncurveRev(y) = y / s below the respective break points?