But they all have the same UID, and are technically "the same user", even if you foolishly confer disparate usernames and passwords on them. When the system reverse-maps their UID it will display "root" because there is, ultimately, only one superuser on Unix.
The situation is the same for any userid and any groupid. If you try creating three ordinary users with a UID of 3005, they will be, essentially, the same user. There is no way at the system level to differentiate them, after they have authenticated. Because their files and processes are owned by the same UID.
This sharing of UIDs is generally discouraged and quite undesirable. It makes systems administration a real mess.
There is an old practice of having an alternative `toor` user with UID=0, with a different shell and password, in case someone screws the primary `root` account. https://en.wikipedia.org/wiki/Toor_(Unix)
If you try and set up "separate users" with "separate $HOME" that map to the same UID, all those "users" will "own" all those same files, and all processes started by one another. They would be able to kill processes, delete/modify/add files, impersonate one another. Because they are the same user.
You would be unable to enforce quotas or privacy for any of them. Whatever they did on the system would be indistinguishable, because their process UIDs would be identical. Any files they created would be owned the same. Sure, set them up with unique lists of GIDs; it really doesn't matter in the end.
I have no idea what you mean "User is user", but you are right: UID is not the same as a username. The username exists only in the passwd(5) database, and not in the kernel, like at all. The kernel has no idea what usernames are, and that's why they're irrelevant to user administration.
