The idea behind the /64 minimum was to make auto-configuration easier - you could just stick the layer 2 ID (i.e. the MAC address) in the second half and not have to worry about collisions or stateful assignment system like DHCP. Remember that IPv6 was designed in the mid-90's, so both of these decisions seem silly now - using the MAC would be a serious privacy issue (modern operating systems use a random ID which changes frequently) and DHCP is very mature.
Yeah I was going to touch upon that. I understand where they were coming from design wise (apenwarr's post is fantastic for that - https://apenwarr.ca/log/20170810). Privacy extensions mainly seems like doubling down on an unworkable idea. I can see the hypothetical benefit on a shared network, where say a coffee shop has a /64 and you can have every single app looking like a separate device on that network to an outside observer. I just foresee the inevitable future where IP surveillance databases contain information like "this /48 hands out /64 to each end user, so treat it as one entity", rendering those extra bits as a mere liability to be mitigated.
Sure, but as the ancestor comment mentions, SLAAC has no relevance for the use-cases people in this thread want more then 64-bits for (e.g. Docker sub-networks). Since your Docker containers don't have "MAC addresses", there's no reason that you need to use 64 bits specifically to configure them. Your container runtime is perfectly positioned to assign IP addresses and subnets however it chooses to. Assigning a /72 to each container is perfectly fine.
The idea behind the /64 minimum was to make auto-configuration easier - you could just stick the layer 2 ID (i.e. the MAC address) in the second half and not have to worry about collisions or stateful assignment system like DHCP. Remember that IPv6 was designed in the mid-90's, so both of these decisions seem silly now - using the MAC would be a serious privacy issue (modern operating systems use a random ID which changes frequently) and DHCP is very mature.