No reason "Let var = PINSC<cr><lf>" shouldn't be supported as far as I can see as it's just a special syntax case in the assignment parsing, unless there's something peculiar with the parsing engine.
In fact it would be possible to use PINSC as if it were a variable in expressions in most cases by detecting a reference to PINSC, prefixing a "PEEK $07,infra" and using 'infra' / 'keyvalue' as the actual PINSC variable. That it corrupts the 'infra' variable can be noted in the manual and only a small minority of people ( I'd say none ! ) would likely be using 'infra' and PINSC in the same expression. That way it would also be possible to have "IF PINSC = $xx THEN".
The same could apply to "LET var = outpins" rather than "READOUTPUTS var", but as I'm not having to do the work I would say "READPORTC var" would be an acceptable compromise and in line wth existing practice and convention.
I'd personally take the trick of using 'infra' ( or some other temporary variable ) to the next level and allow commands to be used as functions, for example ...
LET b0 = READADC(1)
LET b1 = PEEK($07) ^ $FF
When there's no following maths that can optimise to what the existing commands are, otherwise prefix that command using the temporary variable then use that in the rest of the maths. As with unary operators (NOT,DCD) only allow functions at the start of the line.