Reördering SVt_* constants; "internal" SV type

(By the way, we currently have 56 different PRs marked
"defer-next-dev", awaiting the 5.44 release, and I'm still in the
process of making the problem worse. ;) Anyhow...)

I have a few separate branches and items of work that all seem to be
hitting upon a common problem. Namely, that I would like it if certain
properties about SVs could be easily determined by a cheap number
comparison on SvTYPE. In particular, I would really like it if we could
write out comparisons in the following forms:

  An SV should be treated as a Perl-visible scalar
    if SvTYPE(sv) <= SVt_PVMG

  An SV is a safe for Perl code to operate on
    if SvTYPE(sv) <= some-other-value  (which would exclude a few weird
                                       oddballs)

However, these comparisons don't work due to two annoying values that
are apparently in the wrong place in the order; and thus we can't make
a simple numerical comparison on a contiguous range.

  SVt_INVLIST   is not a perl-visible scalar, in fact should not be
                visible to any perl code anywhere for any reason, but
                it sorts right after SVt_PV and before SVt_PVIV and is
                thus accidentally included in the above scalar test

  SVt_PVLV      should be treated like a perl scalar with lvalue
                side-effects, but its value is listed after SVt_REGEXP
                and SVt_PVGV, which aren't really regular scalar values

I'd like to fix both of these problems.

I know there are some ordering constraints involved in the SvTYPE
values, but I don't believe it would be too problematic to move
SVt_PVLV to just after SVt_PVMG (and thus allow a contiguous range for
scalars).

For various other work (e.g. making attributes lexically visible in the
pad) I am working on adding an SV type for "things that need to be SVs
for some reason, but definitely shouldn't be Perl-visible values". I'm
designing it specifically so that INVLISTs could be moved to part of
that rather than needing their own SV type. While I'm at it, I'd ensure
that this new SVt_INTERNAL type definitely lives at the very end of the
list, keeping it out of numerical range tests on most of the other
sensible properties.

Can anyone foresee any problems with this as an overall plan? I intend
to put it together soon so it can be used by my attributes-v2 branch,
as well as for the bugfix for https://github.com/Perl/perl5/issues/24470

-- 
Paul "LeoNerd" Evans

[email protected]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS