Now one can use an update such as

update mysql.global.priv set privs=json_remove(privs, '$.password') where user='root';

or even

update mysql.global.priv set privs=json_remove(privs, '$.plugin', '$.password', '$.auth_or') where user='root';

to remove all traces of authentication for the root user.

I can make it simpler (patch attached), just restart server with skip-grant-tables and run

flush privileges;

set password for root@localhost='';

But after MDEV-12484 this should be a moot point, because the root user will always accept connections without a password, so one will be able to connect normally and reset or change the root password without restarting the server in --skip-grant-tables

We need to find a good place in the KB for the new suggested syntax.
I don't think MDEV-12484 completely eliminates the need. Apart from corner cases, like admins with limited sudo rights (can restart the service, can't run mysql client, etc.), or problems like unavailable unix_socket plugin, or re-configured grants for not using the plugin, there is a big non-corner case, Windows. I see MDEV-12484 mentions auth_namepipe in the description, but never later, so I assume it doesn't come along with it.

Some answers

how to connect to the server after installing the server system-wide (used to be -uroot without the password or with the password set upon installation, not anymore);

Not on Windows: There are two password-less accounts, root@localhost and whatever user owns the datadir (usually it's mysql), also @localhost. To connect one could use sudo mysql or sudo -u mysql mysql. The second should be a safer solution for scripting, because scripts won't need to run under system root credentials.

After connecting to the server one can use SET PASSWORD to set a root@localhost (or mysql@localhost) password and access it in the future without sudo (but with a password), if needed.

on Windows — nothing changed, I presume (mysql_install_db doesn't apply)

how to connect to the server after installing the server locally, under a non-root user (used to be -uroot without the password or with the password set upon installation, not anymore);

Same as above. The second password-less account is for the user who owns the datadir. So, after installing MariaDB locally under a non-root account, simply run mysql.

what, if any, considerations regarding compilation options need to be made when compiling the server from source;

If one disables unix_socket, say with -DPLUGIN_AUTH_SOCKET=NO (or simply starts the server with --disable-unix-socket) the above will not work, one should either not use mysql_install_db in this case, or start the server with --skip-grant-tables and update privilege tables to not refer to unix_socket plugin.

how to troubleshoot and fix the broken auth info (used to be via -skip-grant-tables + flush privileges, not anymore);

--skip-grant-tables + flush privileges + set password or alter user

how to see all users' configuration (used to be select user, host, plugin, ... from mysql.user, not anymore);

for example... select user,host,json_detailed(Priv) from mysql.global_priv but this is peeking into internal data, they can change any time in any way and in any release.

how to reset the password if unix_socket can't be used (used to be via mysql.user update, see comments, but fix the syntax of the suggested update);

ALTER USER or updating mysql.global_priv but see the disclaimer above.

how to update users in bulk (used to be via mysql.user update, probably not anymore);

by updating mysql.global_priv but see the disclaimer above.

Also, MDEV-12484 needs to be documented. The new default configuration created by mysql_install_db makes two all-privilege users. One is root and the other is whoever owns the datadir. The logic is that these two users can access all the data anyway, so the password doesn't add much protection. Both users are created with IDENTIFIED WITH mysql_native_password USING "invalid" OR unix_socket. Meaning, one can connect if the system user is root or the datadir owner. And one cannot connect with a password. But after logging in one can use SET PASSWORD to change the password to something valid and then connection with a password (and without sudo) will work too.

It's been closed, but I still can't even find where it was documented.
I go to mariadb.com/kb and search for 'authentication', which I think is a reasonable way when you do not know the exact name of the article, and I get the first page like this:

Pluggable Authentication
Authentication Plugins
Authentication with Pluggable Authentication Modules (PAM)
Authentication Plugin - mysql_old_password
Authentication Modules in MaxScale
Authentication Plugin - SHA-256
Authentication Modules in MaxScale
Authentication Plugin - GSSAPI
Authentication Plugin - ed25519
Authentication Plugin - mysql_native_password
Configuring PAM Authentication and User Mapping with LDAP Authentication
Authentication Plugin - Named Pipe
Authentication Modules in MaxScale
Authentication Plugin - Unix Socket
Authentication Plugin - PAM
Configuring PAM Authentication and User Mapping with Unix Authentication
GSSAPI Authentication with MariaDB Connector/J
COM_CHANGE_USER
MaxScale GSSAPI Client Authenticator
GSSAPI Client Authenticator
MaxScale GSSAPI Client Authenticator
Connecting
COM_RESET_CONNECTION
MySQL Authenticator
PAM Authenticator

... and 10 more pages to go, every next one looking worse than previous ones.

Please make sure the documentation is findable for anyone other than the authors.

greenman: https://mariadb.org/authentication-in-mariadb-10-4/

Re-opening to keep on the radar, and incorporate Sergei's blog post

Further user feedback incorporated, nothing for a while so can be closed