The idea with this task is to disable 'normal' users from changing local variables that are mainly meant for testing.
Allowing changing of variables, like max_session_mem_used, can expose bugs in the server that a would never happen during
normal operations.

Of course the aim is to fix all bugs that can cause crashes. However we should concentrate our efforts on bugs that hits normal users, not bugs that are causing of setting system variables to unexpected values (like giving all or almost no memory to connection).

To prevent bugs caused by too low max_session_mem_used, max_session_mem_used should not allow very low settings (or my be only in debug builds).

Another use case is to prevent users from setting max_session_mem_used too high after the DBA has limited per-session memory usage. This can be solved with a --max* my_getopt prefix. The feature could be to allow SQL access to it.

I agree with the point about prohibiting too low values. I think it should be done in any case, regardless whether permissions remain the same or not.

It is however still reasonable to limit permissions to "technical" and/or low-level variables (as opposed to business-logic-related variables) to privileged users only.

RIght, that's exactly what I mean. "prevent normal users from changing local variables ... to unexpected values (like giving all or almost no memory to connection)" is one task. "prevent users from setting max_session_mem_used too high after the DBA has limited per-session memory usage" is another task. "Require specific privileges to change certain session variables" is a third task.

This MDEV-24065 cannot be implemented until it'll be clear what task it is.