on the other hand, existing documentation and tools that work with sys schema rely on configuration table.

perhaps it might be better to keep it for compatibility reasons

serg, do you mean to keep the table as a system view while adding system variables, like table GLOBAL_VARIABLES

no, I mean to preserve the table-based config like in the original sys schema

From examining how it is used , I do not think that this functionality (sys_config) is so important that it will make any problem if table-based is replaced with session variables.

I mean, we can speculate whether compatibility reasons are important or not, and continue to live with "session variables emulation in SQL" Frankensteinian creation, or try to remove it and see if anyone complains.

At least we can remove the code like this from the sources,

  -- Check if we have the configured length, if not, init it

  IF @sys.statement_truncate_len IS NULL THEN

      SET @sys.statement_truncate_len = sys_get_config('statement_truncate_len', 64);

  END IF;

I don't believe this will make a huge difference for tooling and users, because currently sys doesn't have many, or superuseful, configuration variable.

But why is the table a "twist"? performance_schema has configuration tables, too. (Yes, I understand the reason and the difference, but still it has configuration written into tables)

You say that sys schema is now integrated. I'd say it's not integrated, it's just installed by default. In my opinion this is great, because it allows to make changes easily without changing MariaDB code.