IPCP itself doesn’t really know about “framed routes”, which is just an implementation detail on the PPP server side. (And it actually is a long-standing pity both that IPCP can’t tell the connecting client what IPv4 CIDR prefix it might be getting “delegated”, necessitating that the end-user just “knows” what those addresses covered by the Framed-Route are [so in this respect, PD through DHCPv6 has got IPv4 beat, hands-down], and also that IPCP cannot inform the connecting client of specific routes that it should install on its own end, requiring hacky solutions like scripts on the client side that have prefixes hard-coded in them, or …barf… RIP. But I digress.)
In fact, the larger problem here, when it comes to the “pure-IP” generations (4G/5G) of 3GPP networks specifically, is that GTP seems to be not merely just a simple wrapper around garden-variety PPP. Given how traffic is tunneled and state is signaled through different “interfaces” within the core, as well as how address tracking/mapping is done within most 3GPP EPCs/cores, in the same way that IPv6 PD isn’t a thing (or, at least, wasn’t until roughly 5 minutes ago, counted in “mobile network” years 
), pointing whatever IPv4 CIDR prefixes that you want to route at individual UEs also typically isn’t a thing (barring vendor-specific extensions that you can’t count on being present in any 3GPP core that you might sit down to work on). If it’s standards-compliant and nothing more, then it’s one IPv4 address per bearer, period. No “framed routes” for you! Thus a NAT44 on the LTE client side (one that is serving up a “hotspot”, or otherwise acting in the capacity of a fixed broadband connection) is simply an unalterable reality for 99.9% of the user-base.
I’m actually sufficiently satisfied that this has been addressed well enough (at least on the SLAAC side) through mechanisms such as RFC 6204. Though this is something that RouterOS (in)famously took until v7.9 in A.D. 2023 to actually support, lol. And so had to be worked around via complicated scripts prior to that (still thankful ROS even has this sweet scripting mechanism to begin with, to be perfectly clear!) Of course, this still requires that your WAPs be configured to proxy MDP and convert to unicast, so your wireless clients can be guaranteed to even hear the signal that instructs them to invalidate the expired prefix to begin with. 
I realized just now that I’m actually not sure, though, how well the DHCPv6 server handles this scenario. Guess I’ll add that one to my ever growing list of things to lab…
All of these things also just speak to how you need to have all of your IPv6 ducks in a row end-to-end for this to work and be a satisfying experience for the end-users whose networks and connectivity you are responsible for. It would be irresponsible to just flip the IPv6 switch on across the entire network without first testing all of these factors all the way from the network core to the customer-side of the last mile, finding fixes or work-arounds for all of the contingencies you run into ahead of time, etc. Because WHEN (not if) customers start experiencing problems, with them unaware that you started serving them IPv6 reachability or even knowing what that is or that it is even a thing, you need to be able to support them! Blithely turning it on and breaking people’s networks or “quality of experience” in the process is a recipe for disaster.
Yes…my “PBX” analogy/argument.
Perhaps. But DHCP clients still do more often than not tend to transmit some kind of hostname along with their request, which can often give you a clue as to what you might be looking at. (Though I will note that I have seen a trend where devices likely to do MAC randomization, like smartphones, are also moving more and more towards not including a hostname as well.)
I think you misunderstand. My problem is not that they implemented SLAAC, which is clearly a mandatory thing for a client to implement. My problem is that they didn’t ALSO implement DHCPv6, and steadfastly refuse to extend Android to add support for it, “out of principle”. SLAAC and DHCPv6 is not an either/or thing. In fact, DHCPv6 in single-addressing mode still depends on the RA mechanism (flags are set in the transmitted RAs to inform hosts that there is a DHCPv6 server on the network that they can or even should reach out to). There are even many scenarios wherein a host will both generate a SLAAC address and also obtain one via DHCP, which is a perfectly legitimate config.
I think you are just re-making / re-stating my point for me. 