Latest stable release, 3x HAP AX3 (CAPS client) + RB5009UPr (CAPS manager) with some additional CRS312/CRS305 switches in service.
Client: up to date iPhone 15 Pro Max (among others)

When I connect 2.4GHz or 5GHz using good WiFi reception everything is fine.
However, when I move to a room where the signal quality is slightly worse, my client gets roamed to another HAP, which is one story lower in the building.
After that, the client is almost immediately forced to roam back to the previous AP, and then again to the HAP one story lower.
After these three roamings, the client disconnects and switches to 5G cellular to maintain an Internet connection.

I did not notice this behavior few weeks back. Nevertheless, something could be off with my config as I upgraded my CAPSman device from an L009UiGS to a more powerful RB5009UPr, connected over the Mikrotik passive SFP 10/25GBE cable (was previously 1GBE with the L009UiGS).

Here you can see the relevant log entries (MAC removed for obvious reasons ): Furthermore, I still get warnings about "disconnected, SA Query timeout, signal strength -78", although they have become fewer after enabling "FT" and "FT over DS" for every WiFi interface.

Are these issues known? What shall I try?

Turn on wireless debug logging.
Might work better of security is set to wpa2 aes only.

Tried WPA2 AES, no improvement.
Enabled debug logging: Any thoughts?

Roaming is always a RPITA, even on public mobile networks (e.g. LTE) where roaming/handover mechanizms are waaay better that what we have in WiFi. And the only solution is to design wireless signal coverage so that AP signal overlap (areas with similar signal strengths where stations want to roam to another AP) doesn't happen where stations tend to be most of time. E.g. you want to have signal overlap in the middle of corridor or in the staircase, you don't want to have it on living room sofa or on office desk. And you do that (preferrably) by moving APs or by reducing some AP Tx power to shrink range a bit. Roaming can be made much slower by disabling all roaming features, but in this case roaming entirely depends on each station's individual behaviour and is thus much less predictable (so you probably don't want to do that).

A "strange" thing is that the signal from a lower floor AP can reach the upper floor with enough power to "disturb".
There is an ongoing thread (actually a couple of them) specifically about the Ax3 and the capabilities of its "big ears" antennas.
The theory is that the signal is radiated in a (fattish) doughnut shape from the antennas, so if the antennas are vertical no or very little signal should be emitted upwards, and as a matter of fact the suggestion about multi-floor coverage is to have the two antennas at 45 degrees or one vertical and one horizontal (90 degrees between them).
Maybe in your case (if you are keeping them parallel and vertical) there are particular reflections/whatever that allow signal to reach the upper floor?

Vertical parallel antennas. Still, this issue was introduced by me or the firmware recently.
Rolled back to 7.13.3 where I thought the issue did not exist then. Still there.

The statement to minimize overlapping zones is preferred (obviously), but there must be an overlap to perform the handover.

According to my understanding, the ping-pong of the handovers is the problem.

There should be a slight delay for subsequent handovers (to make one and then wait what happens), and/or the signal difference required to initiate one must be much higher.
We should be able to specify both parameters.

Three handovers within few seconds is way too much and almost never an appropriate solution for a typical WiFi user.

There should be a slight delay for subsequent handovers (to make one and then wait what happens), and/or the signal difference required to initiate one must be much higher.
We should be able to specify both parameters.

Three handovers within few seconds is way too much and almost never an appropriate solution for a typical WiFi user.

In WiFi, even with mobility features enabled (802.11 r/k/v), it's always station which decides to roam to another AP. The only difference is that without mobility features stations tend to stick to one AP until almost loosing the signal before connecting to a much better one. Apart from disconnecting a station (which is even more disturbing action), AP doesn't have any role in decission making.

BTW, the logs, shown in first post, actually show two "roamings" in 3 minutes time (with a possible third one, the earliest log entry shown might be part of messages of a previous roaming). The first one is weird as station seemingly roamed to a worse AP (signal strength -72dBm before move, -78dBm after) so device decided to head back (probably, you redacted AP names so we can only guess).

And: I didn't say that signals of adjacent APs shouldn't overlap, I said they should overlap in areas where stations don't linger but rather pass (swiftly).

Thank you all for your feedback and pointing me to the right direction!

Identified and resolved the issue:
On the CAPS managed HAP AX3 AP (at the story below) two of the three WiFi entries (WebFig: Bridge -> Ports) were not bridged to the default bridge and thus they didn't offer LAN/Internet access.

Therefore, the iPhone wanted to connect to the other AP due to better reception, but got no internet and then tried to connect back and switching back to 5G.

Strangely enough, the complex dynamic WiFi was correctly bridged and only the regular "wifi1" and "wifi2" interfaces were just listed as "unkown" (= no interface assigned).
No clue how/why these two interfaces dropped.

This is one major drawback when using Mikrotik: when you change something somewhere or install an update, then at a completely different location something (which should not be related) could break. Would be great if we would get kind of a list of related changes throughout the system if changes will have an impact somewhere else.

Another (rather minor) example of such behavior:
When you choose a particular country in the WiFi channel settings, then you configure something invalid with the frequency ranges, then the country will drop, but you only notice that if you check manually.

Besides these hickups, Mikrotik WiFi seems to work quite reliable these days when configured correctly (even with default settings).