what does suse/Ubuntu do different?

I cannot speak for SUSE but Ubuntu Core experiences this problem in two different ways:

Ordinary application squashfs cannot use users or groups ot eh we than root. This is sometimes problematic and requires patching applications to compensate. The reason for this is that one cannot allocate such IDs at runtime and some mimetic value must be baked into the signed disk image.

The second problem is that the same base squashfs snap is used on Ubuntu Core distribution, classic Ubuntu, Debian, Fedora and any other. In all the cases the user and group database is provided by the host and, outside of core itself, may not line up exactly as one would want.

OSTree/bootc build an image. Every update is basically a fresh image with the packages installed from scratch into the image, which leads to the ordering issue. As far as I understand with the SUSE atomic versions they use traditional system updates combined with btrfs snapshots. So when an update is done, a new snapshot is made, the snapshot is mounted read-write and various directories are mounted on top of it. Then the read-write snapshot is updated using Zypper as a normal, mutable SUSE system. If the update failed, the snapshot is discarded. If the update was successful, the snapshot is unmounted and then mounted as the read-only root during the next boot. It doesn't have the UID/GID issue, because aside from the tricks to make root read-only, it updates in the same way is a non-atomic Linux system.

Disclaimer: I don't use SUSE, this is what I found based on the documentation.

> I wonder what Ubuntu and suse do different in their immutable versions to avoid this issue.

SUSE does not ship /etc/passwd or /etc/group but generate that at install time, we do that at least for MicroOS and derivatives, and add new users via sysusers.d at update time.

The /etc directory of most Linux distributions contains four kind of files:
* host specific files generated at install time or first boot, like /etc/machine-id, /etc/passwd, /etc/group, ...
* distribution provided configuration files, which admins and distributors can change
* admin made changes
* stuff which does not belong to /etc, but where upstream projects are reluctant to fix that. Why do we need shell scripts for grub in /etc?

If you update that with a package manager, the package manager will try to merge that for you. If you have an image based system, that's not possible. That's why I don't understand why some image based distributions could come to the idea to ship /etc with their image. It's a big mess if you update the image.

The mid- to long term plan for SUSE is to have a hermetic-usr system. For many core package we have that already, but it's still a long way to go, especially as many upstream projects are not interested in this and reject patches.
But that's the only clean solution for the current /etc mess in update case, even for traditional distributions.