That issue does not actually prevent 802.11r roaming. (at least in main/master. I am not using 23.05)
With my Android 11 tablet, I have success with "WPA2 only" roaming, but not with WPA2/WPA3 mixed or WPA3 only. (My newer phone roams WPA3 ok.)
See the log, there is first the key addition error and then the successful FT roaming.
Sat Oct 21 11:27:44 2023 kern.info kernel: [ 1640.508581] br-lan: port 5(hn5wpa2r) entered forwarding state
Sat Oct 21 11:27:54 2023 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'hn5wpa2r'
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 IEEE 802.11: authentication OK (FT)
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 MLME: MLME-AUTHENTICATE.indication(e0:c3:77:ae:0a:30, FT)
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 IEEE 802.11: association OK (aid 1)
Sat Oct 21 11:27:54 2023 daemon.info hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 IEEE 802.11: associated (aid 1)
Sat Oct 21 11:27:54 2023 daemon.notice hostapd: hn5wpa2r: AP-STA-CONNECTED e0:c3:77:ae:0a:30 auth_alg=ft
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 MLME: MLME-REASSOCIATE.indication(e0:c3:77:ae:0a:30)
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'hn5wpa2r'
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 WPA: event 6 notification
Sat Oct 21 11:27:54 2023 daemon.debug hostapd: hn5wpa2r: STA e0:c3:77:ae:0a:30 WPA: FT authentication already completed - do not start 4-way handshake
Also the key management is properly recognised as FT=802.11r:
root@router4:~# /etc/wifi-suite.sh
Associated wifi stations' AKM suites:
hn5wpa2r: AKM suite of e0:c3:77:ae:0a:30 is 00-0f-ac-4 (WPA-PSK-FT)
Example of my working config:
option ssid 'WPA2RKOE'
option encryption 'psk2'
option key 'XXXXXXXXXXXXXX'
option ieee80211r '1'
option ieee80211w '2'
option ieee80211k '1'
option wnm_sleep_mode '1'
option wnm_sleep_mode_no_keys '1'
option bss_transition '1'
option max_inactivity '4500'
option ft_over_ds '0'
option ft_psk_generate_local '0'
option reassociation_deadline '20000'
option disassoc_low_ack '0'
option sae_pwe '2'
option ocv '1'
option pmk_r1_push '1'
option nasid 'rt3200'
option mobility_domain '4488'
option r1_key_holder 'c4411EF8A521'
list r0kh 'DE:EF:09:EF:F3:E6,r7800,3ed67e18b353c6d80f5242e98e58a7efae9b9bc93903ecc32473c90c3c136ac6'
list r1kh 'DE:EF:09:EF:F3:E6,DE:EF:09:EF:F3:E6,3ed67e18b353c6d80f5242e98e58a7efae9b9bc93903ecc32473c90c3c136ac6'
list r0kh 'C4:41:1E:F8:A5:21,rt3200,3ed67e18b353c6d80f5242e98e58a7efae9b9bc93903ecc32473c90c3c136ac6'
list r1kh 'C4:41:1E:F8:A5:21,C4:41:1E:F8:A5:21,3ed67e18b353c6d80f5242e98e58a7efae9b9bc93903ecc32473c90c3c136ac6'
I have noticed that sometimes the automatically allocated MACs slightly change, e.g. C6:41:1E:F8:A5:21 instead of C4:41:1E:F8:A5:21 according to the enabled SSIDs enabled etc., so you may need to check the key_holder and r01kh and r1kh data.
(I should probably assign permanent MACs to avoid that kind of trouble.)