Added Compatibility label, as MySQL 8.0 has SET PERSIST (and SET PERSIST_ONLY).

https://dev.mysql.com/doc/refman/8.0/en/reset-persist.html

RESET PERSIST [[IF EXISTS] system_var_name]

1) what if there is no any config file?
2) what if there is write rights to the file?
3) command line option will still prevail, so it will be the same effect in case of command line options
4) allow server to write to setup looks (for me) like a security risk

I hope these questions are not for me.
But I can drop an opinion:
1) create the file and fill it
2) inform with "Unknown error" or something
3) that's OK if command line option prevail, it desired to work in no command line option mode like SET tells
4) the same user can drop tables, users, so it's OK for him to rule the settings of the database

4) is about having code which rewrite config in the server.

5) rewriting confing is far from be atomic so you can just destroy config (tables looks way better at least aria are crash safe)

To answer sanja's questions according to how MySQL does it:

1) It creates a separate file, mysqld-auto.cnf
2) It doesn't attempt to write to any other config file, so this should not be an issue
3) No, until RESET PERSIST... is run, this takes precedence over options set on the command-line.
4) This is written in the data directory only
5) Agree, which is an argument for writing in a system table instead

More info:

• https://dev.mysql.com/doc/refman/8.0/en/persisted-system-variables.html
• https://mysqlserverteam.com/mysql-8-0-persisting-configuration-variables/
• https://www.percona.com/blog/2019/08/13/set-persist-in-mysql/

no I am strictly against ability of the server to write any configuration file

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.