In my opinion bb-10.11-MDEV-7567 as of 27b7d5d can be pushed into 10.11 main and released with 10.11.1.

The final change is:

The new variables are already documented in the KB, with a minor error to fix MDEV-29689.

As of 36b42630:

• the branch cannot be pushed into main as it fails in buildbot with numerous mismatches (result files not updated) and MTR aborts before all tests have been run. It needs to be fixed;
• comment in MDEV-29625:

  From the list in the description, mariadb-report, mysqldumpslow.sh and mysql_client_test remained unchanged. Is it intentional?

  It doesn't necessarily have to be fixed, but needs to be clarified.

Please reassign it back to me when all planned fixes are in and the branch is rebased.

As of bb-10.11-MDEV-7567 957ac458a:

• MDEV-29594 (32-bit test failures) – needs to be closed, as it's apparently fixed
• MDEV-29626 (Assertion failure) – needs to be fixed
• MDEV-29595, MDEV-29625 (names and uses) – need to be either fixed or demoted or closed as "won't fix"
• MDEV-29598 (description reference) – optional

Please reassign it back to me when all planned fixes are in and the branch is rebased, I'd like to take a look at the resulting status before it's pushed into main.

There is an ambiguity in MDEV-29297 which, I think, may affect the approach to this task.
If the idea of MDEV-29297 is that eventually the deprecated variables/options will start getting rejected, and server startup will start failing, then I think it would make sense to start deprecating (throwing a warning) about the old names of slow-log-related variables/options already now, not waiting for the total sweep in MDEV-29297. It wouldn't be unusual, we already have some deprecated variables here and there. The reason to rush is that slow-log-related options are old and quite widely used, it will take long time to get rid of them; the longer the period between the warning and startup abort, the more chance that the old configuration files will get amended in time.
If, on the other hand, MDEV-29297 implies that the options will be accepted forever, despite the warnings and their absence in sysvars, then there is no such urgency.

There was some back-and-forth in this task, so, to summarize, as of bb-10.11-MDEV-7567 3b3ce1fbca here is what is de-facto there:

log_slow_min_examined_row_limit (min_examined_row_limit)

log_slow_query                  (slow_query_log)

log_slow_query_file_name        (slow_query_log_file)

log_slow_query_time             (long_query_time)

It remains unclear what was the role-model for log_slow_query_file_name.
We have a variety of patterns with similar meaning:
general_log_file
relay_log_info_file
wsrep_status_file
pid_file
log_error
log_bin_basename
innodb_buffer_pool_filename

but I couldn't find any %_file_name (maybe somewhere in optional plugins, those I didn't check).

So, maybe it should be just log_slow_query_file, like several existing _file's. Or even just log_slow_file, given the variable list

+---------------------------------+

| log_slow_min_examined_row_limit |

| log_slow_slave_statements       |

| log_slow_query_time             |

| log_slow_verbosity              |

| log_slow_admin_statements       |

| log_slow_disabled_statements    |

| log_slow_query                  |

| log_slow_query_file_name        |

| log_slow_rate_limit             |

| log_slow_filter                 |

+---------------------------------+

Filed as MDEV-29595 so that it's not forgotten, with an additional note for an extra fix in help text.