A certain LDAP user is always created with UUID as name, thought this is disabled

I’ve linked Nextcloud to an LDAP service for user management. At first, the Nextcloud representations of the users showed up with an UUID as username, which made them completely unusuable. So, I went to Administration Settings->LDAP/AD integration, opened the expert tab and set Internal Username to “cn”, which represents my unique username. Afterwards, I deleted and recreated all existing users on LDAP.
Now, if I create an LDAP user with a name (cn attribute), it is correctly created with the cn attribute as it’s username. This goes for every user I tested, except for one which goes by the simple name of “a”. This one user is always created with an UUID just like in old times.
You might ask, “Is this important”. No, It’s actually not, a user “a” will problably never exist in reality, but I’d like to find out what’s happening.

Executing the command sudo -u www-data php occ ldap:show-remnants in /var/www/nextcloud returned a lot of old entries which I deleted, the remnants table is empty now. Still no change in behaviour.

Where do I find this mysterious mapping entry? Are there any other LDAP caches I should be aware of?

It can be a broken cleanup of tombstones (if using AD) or Obituaries (if using NDS). It most likely has a specific verb in the Directory service of your choosing, but look at https://ldapwiki.com/wiki/Eventual%20consistency

However an LDAP can never be completely empty, so it can also very well be your scoping?

Besides of these two very theorethical possible reasons, I have no further clue. I just knows these two possible, but very rare and unlikely scenarios, could cause that behavior.

For AD: