Unable to boot on my APFS partition

Here the current superblock of the APFS container (block0 of disk0s2) was overwritten with an MBR. This will prevent the boot loader (and diskutil/Disk Utility) to recognize the APFS container as such.

A normal superblock (different Mac & different container size though) looks like this:

No real reason could be found why the superblock was overwritten!

To fix this (via TeamViewer & external boot volume with Catalina installed) another (older) superblock of disk0s2 was used to overwrite the MBR data.

1. Install HexFiend and search for the magic bytes of a superblock: NXSB on partition disk0s2. The first occurance was after the first ~3 GB of disk0s2. The metadata part of an APFS container usually houses various older superblocks. The current superblock usually is the copy of one "older" superblock if the Mac was shut down properly previously.

   Although thereʼs only one container, there are several copies of the container superblock (an instance of nx_super block_t) stored on disk. These copies hold the state of the container at past points in time. Block zero contains a copy of the container superblock thatʼs used as part of the mounting process to find the checkpoints. Block zero is typically a copy of the latest container superblock, assuming the device was properly unmounted and was last modified by a correct Apple File System implementation. However, in practice, you use the block zero copy only to find the checkpoints and use the latest version from the checkpoint for everything else. Source

   The size of a superblock appears to be 1382 Bytes. Since an MBR has a size of 512 Bytes, I expected that the latter 870 Bytes (1382-512) of the superblock haven't been overwritten and decided to copy only the first 512 Bytes of an older superblock to keep as much as possible of the leftovers of the original one.

2. dd the 512 Bytes of this older superblock to a file on the desktop:

   sudo dd if=/dev/disk0s2 of=/Users/user_name/oldsuperblock.bin bs=1 count=512 skip=3063808000 #"3063808000" is just an example Byte offset because the zsh history file with the original command is lost
   

3. dd the file to block0:

   sudo dd if=/Users/user_name/oldsuperblock.bin of=/dev/disk0s2 bs=512 count=1
   

4. Reboot the Mac to the temporary boot volume to "reload" the APFS superblock of the internal APFS container

5. Repair the APFS container (with encrypted volumes!):

   diskutil repairVolume disk1
   

   diskutil (or better fsck_apfs) complained about a wrong checksum of the superblock but fixed it without any trouble.

6. Check if the encrypted Data Volume can be mounted with Disk Utility > Mount. To unlock the volume a password of a user of the "broken" disk has to be entered.
7. Boot to the internal boot volume
8. SUCCESS!

Conclusion:

I haven't been able to find any numbering scheme or time stamps for superblocks in the Apple APFS documentation or by comparing the various older versions of the superblock I have found.

It's unclear whether it was pure luck to fetch a working older superblock. No current backup was available so it's even more uncertain whether reinstating an old superblock leads to data loss. At least the Mac booted and the encrypted volumes could be unlocked.