Comment 5 for bug 1911999

# Argument why (b) might in fact a problem: "disk should be detected as new, and not mapped onto the old paths/devices"

Obviously one could just say "have a static LUN Id plan and don't map back the old LUN, but that is evasive. In a perfect world something in kernel/udev/multipath would recognize it is a new thing.

I agree that if you "map a different / new disk to the same lun" things should not totally break as you reported. I'd have expected that it would detect e.g. a UUID and only do so if these match.
Do in your case the UUIDs also stay the same when you map a new disk under the same LUN?

In my case (adding back the same disk under the same LUN) nothing changed.
For example sg_inq reports absolutely the same

$ sudo sg_inq --id /dev/sdh
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 20
    designator_type: NAA, code_set: Binary
    associated with the Addressed logical unit
      NAA 6, IEEE Company_id: 0x5076
      Vendor Specific Identifier: 0x306ffd6b6
      Vendor Specific Identifier Extension: 0x240a
      [0x6005076306ffd6b6000000000000240a]
  Designation descriptor number 2, descriptor length: 8
    designator_type: Relative target port, code_set: Binary
    associated with the Target port
      Relative target port: 0x130
  Designation descriptor number 3, descriptor length: 8
    designator_type: Target port group, code_set: Binary
    associated with the Target port
      Target port group: 0x0

Be careful as there are plenty of UUIDs.
The one of the FC/SCSI layer (sg_inq).

Then there could be some below on GPT and on Filesystem.
But IMHO multipath works "below" that and most likely only considers the ID of the FC/SCSI layer.
In my test my LUN was totally empty, so I had no Partition/FS UUID at all.

If your SCSI/FC UUID does not change, then I think this is mis-usage/mis-expectation. I'd be unsure what kernel/udev/multipass should do different.
But if your UUID changes, then IMHO it should work. But I wonder if "appearance of a different disk in place of a missing one" was ever considered in mutlipath. I'd ask you to start a discussion upstream [1][2] for "what to expect" and "how to handle" that case.
Please report a link to the discussion here and let us know of the outcome. No matter if it will be:
1. a different config (then everyone tracking this can benefit)
2. a patch we can fix the package(s) with
3. a lessons learned about what to expect from which component (then everyone tracking this can still benefit)

[1]: https://www.redhat.com/mailman/listinfo/dm-devel
[2]: https://github.com/opensvc/multipath-tools/issues