I've resolved my doubts about keeping the columns in existence:

So sufficient as minimal fix is:
bb-10.2-danielblack-MDEV-24122-m57-incorrect-user-table-alignment

Is limiting the cases where the mysql.user structure is tests to !bootstrap, !mysql_user_table_is_in_short_password_format sufficient to not be too much now?
https://github.com/MariaDB/server/commit/045a9d98b9520cede0e22d5b8615c411ed5aaa98#diff-df544694418bef1c4bc6cdc5211ca133e7ad4d31901f16d0fdee8df6e4debe89R2222

cvicentiu can you review and merge if appropriate:

• bb-10.2-danielblack-MDEV-24122-m57-incorrect-user-table-alignment

before reassigning back to serg to look at:

• bb-10.2-danielblack-MDEV-24122-m57-incorrect-user-table-alignment_part2

(which you're welcome to review too).

Hi danblack!

I think the patch is ok. There are a few changes I'd make to help explain the problem more clearly.

1. The JIRA entries are a bit of a mess so grasping the whole history is hard. Let's make a short summary in the commit message. My proposed wording:
   1. For MariaDB versions before 10.2.35, when upgrading from MySQL 5.7 the columns belonging only to MySQL password_last_changed, password_lifetime, account_locked were placed in a wrong order for MariaDB to function properly with roles.
   2. After MariaDB 10.2.35 thanks to MDEV-23201, the columns order is resolved, when upgrading from 5.7, but not if the upgrade already happened with a previous 10.2 (or 10.1) version.
   3. This patch corrects versions that upgraded from 5.7, before 10.2.35, by ordering the mysql.user columns is_role, default_role, max_statement_time explicitly.
      Corollary to this fix in mysql_upgrade, we explictly move the mysql-5.7 columns after the columns used by MariaDB. These columns are:
      * password_last_changed
      * password_lifetime
      * account_locked.
      This is done to facilitate the following process:
      A user could upgrade to MariaDB-10.2, and on a previously common wisdom of MySQL not upgrading more than one major version, and then upgrade to MariaDB-10.3, and then to MariaDB-10.4 in rapid succession, at which stage these columns would actually have a meaning the in migration to the new mysql.global_priv table (where account locking and password expiry have meaning).
      Those that take a slower upgrade path may find that a previously working MariaDB-10.3 user is now locked, or their password is expired. Because of this, the `password_last_changed` has its definition changed to update to the current timestamp, as the MariaDB remains ignorant of its existence. A user changing their password will now keep this field accurate.
      As a fallback, SHOW CREATE USER will however quickly expose the underlying cause.
2. I would not have the long test case in the commit message. You effectively described it in the test case, except that you should show the "problematic" table structure with a SHOW CREATE TABLE. I suggest the following: A SHOW CREATE TABLE right after importing the mysql 5.7 tables and doing the alter to
   "pretend" upgrading with a bugged 10.2.34 or earlier. Keep the SHOW CREATE TABLE after mysql_upgrade.
3. The test case should not have the "for 10.4 do this".
   Instead, make sure you work with the person merging 10.2 to 10.4 to properly merge the patch. Or you can do it yourself.

OK to push from me.
As for part 2, I would just do a simple check when opening the table, looking for this problematic situation, but only for the default_role column. Do a string compare on the column name after opening the table, see if they match. If they do not match, issue the warning and suggest running mysql_upgrade. You can annotate the strcmp with a comment referencing the MDEV that describes the initial problem, caused by cross-grading from 5.7 to 10.2.34 or to an earlier 10.1 / 10.2 version.

danblack, please, for this bug you don't need more than a couple of lines of the commit comment. Something like

MDEV-23201 correctly reordered columns in mysql.user table when upgrading from MySQL-5.7
Here we also correctly reorder columns in mysql.user table from an invalid order caused by an upgrade from MySQL-5.7 to MariaDB-before-MDEV-23201.

Thanks for the reviews