Thanks very much for these thoughts, Domenico!
At first I was thinking of this as "session consent" at the AS for interaction too, but when I looked back at Justin's original description after our call discussion, it was meant more for replacing the original AAT design, which was mainly meant to cover the use of the RPT endpoint through OAuth consent (and technically could only cover consent to use the RPT endpoint and not the claims-gathering endpoint, I think).
So the way it's currently written, the SCT consent is supposed to grant consent for subsequently client-pushed claims rather than any interactions, and thus it's not so much a session token in traditional terms as a consent-based persistence. (Justin was calling it a refresh token, but I was concerned about confusion with both the real refresh token that may be present, and with the fact that it's not a "token" -- it's more like a ticket. In fact, maybe we should literally call it a consent ticket or something?? Except that it doesn't rotate?????)
Agreed about "consent" being a touchy word. Maybe borrow "authorization" directly from OAuth?