So, I believe I figured out what’s going wrong:
When you use miniupncp, it’s fairly straightforward what happens:
Miniupnc first retrieves UPnP device descriptions, checks if all is good, gets external IP etc and then adds the mapping. Once it has the mapping it retrieves it to check, then it terminates.
Note that miniupnc only uses IGDv1 here, not v2.
Syncthing on the other hand does this:
Syncthing both tries to discover IGDv1 and IGDv2 devices. The Fritz!Box answers both (for compatibility probably).
Syncthing then also does the usual data-fetching and then adds a mapping via IGDv1. This is successful.
However, after successfully getting a port mapping, Syncthing doesn’t stop here. Syncthing now attempts to add the same port mapping via IGDv2. The Fritz!Box refuses this, with error code “ConflictInMappingEntry”. This is correct as the port is already mapped. Syncthing retries a few times then giving up, reporting success as the first IGDv1 attempt was successful.
However, the failed IGDv2 attempts apparently trigger a bug somewhere in Fritz!OS UPnP stack, as this causes the mapping to disappear from some UI elements. I can reproduce this by manually creating conflicting entries using a different port mapping tool (GitHub - kaklakariada/portmapper: A tool for managing port forwardings via UPnP). As soon as I try to create conflicts, the UI removes the port mappings, even though they are technically still there and can be retrieved via UPnP. I wasn’t able to reproduce using miniupnc - maybe it has internal guards against conflicting entries.
Note that the issue does not appear to be v1 vs v2: I can still reproduce by adding the same mapping via v1 twice: The UI bug appears as soon as you try to create conflicts using either version.