You’re right, I was thinking of the band steering option to balance clients between frequency. Typically band steering will be used to optimize for speed—force clients to 5Ghz.
Yeah, there is a limited ability to do that sort of thing. I like how they had put it in the article I posted:
Yes there are options available to help manipulate this decision but still, it is that individual client that makes the final decision!
It’s still the client doing the switching, but there are ways to influence the client. It’s still the client calling the shots, but if you control what it sees, you can hopefully “force” it to do what you want.
The 2.4/5Ghz dual band prioritization is an excellent example of that, I’m glad you mentioned it. 
In practice are amendments like 802.11v still not being used? It seems like there are many clients and APs that support them (v, k, and r).
They are used, but the implementation falls to the network stack on the connected device with mixed results. Unifi in particular is infamous for putting out new releases which break these, followed by complaints on the forums that iOS devices keep dropping.
802.11v is what @echoreply was referring to where they said the AP can move the client, but it is the access point telling the client “If you like talking to me, you might also liking talking to my fellow access points b, c, and d”. It’s up to the client to take action.
I don’t know what they’ve changed in the last few years, but my experice with older systems (like Trapeze) was that it was very simple:
There was a controller that talked to each of multiple wifi access points. (AP’s).
The AP’s shared/broadcast the same network name(s)
(you could have multple WiFI on a fancy AP - say, a public Wifi for internet only, and a private one restricted to devices authorizzed to access the servers, etc.)).
The phone/tablet/laptop device was responsible for connecting.
It would listen for braodcasts to build that list you see “which one do you want to connect to?”
Whether it was using a broadcast name or using a rmembered name, it broadcast.
the first AP to respond, usually(!) initiated the connection conversation - tell me the password, here’s your IP address I will associate with your MAC address, etc. (Usually, first to respond is the nearest or perhaps least busy nearby)
Carry on…
Your device will not let go of the connection unless it’s interrupted. The disadvantage is, you may stray to a nearer WiFi but still remain connected to the one you left behind - until the signal no longer works. If connection is lost, it will try to rconnect to the same network name. You may not even notice the interruption, if it happens fast.
Controllers for multi-AP networks use this to their advantage.
They can hear the device on multiple AP’s, and the strength of the signal, even though the connection is on only one AP.
When the controller detects a device is “louder” on a different AP they eventually switch the connection to that AP. But… there is not protocol to do this.
The controller does this by telling the original AP to stop responding. The device will then call out for the network, and the controller tells a different AP to respond.
There are several other tricks. The controller is listening for broadcasts, so can accumulate a list of other network AP’s; you can dedicate an AP to “stomping” on specific rogue networks - whenever another AP broacasts the controller tells its own AP to broadcast at the same time and interfere with their signal. It can also balance channels, strengths, etc.