As far as I understand, the only practical effect of this MySQL feature on real-world environments is bringing uncertainty about the actual servers configuration. It allows to change a variable and make the change survive a restart without changing my.cnf: this is strictly against the modern way to handle systems (infrastructure as code paradigm, devops, SRE, whatever).

I agree that an SQL command should not modify a configuration file. That could even worsen the situation, because the actual configuration file on a server wouldn't match the one you have in your repository.

Please, don't implement this command or any variant.

Even though it's unclear whether this will be implemented, since it's still open, I'm linking it to the parent list of MySQL-8 compatibility tasks.

We could have a special, always included 'persistent.cnf' file in that is modified with SET PERSISTENT ...
This would always be loaded last from my.cnf.
At least, the behavior of this feature would be easy to document and understand

This would still cause inconsistencies between (for example) a user's Ansible repository and MariaDB configuration. Even if the repository contains persistent.cnf, it will be different from the one on the server.

Good configuration management overwrites 'unknown' configuration files like 'persistent.cnf', so this is compatible with what @monty proposed.

Check https://gitlab.com/de-groot-consultancy-ansible-roles/mariadb-mysql-galera/-/blob/beta/tasks/configure-mariadb.yml for an example.