Finally (and sorry for the many comments), I just downgraded to

mysql Ver 15.1 Distrib 10.6.13-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper

and now the dump loads correctly with the exact same settings.

Thank you, the dump was very helpful.
The reason of the error is a conflict between foreign keys with CASCADE action defined on the table in question, and the definition of a virtual column. We couldn't reproduce it with the table from the original description, because the table definition there is abridged, in doesn't have foreign keys (in the dump it does).

The change was made in the scope of MDEV-18114 in 10.6.15 (and corresponding other releases in 10.5+). An example of a problematic structure is t2 here:

--source include/have_innodb.inc

CREATE TABLE t1 (a INT, KEY(a)) ENGINE=InnoDB;

CREATE TABLE t2 (b INT, c INT AS(b) STORED, FOREIGN KEY (b) REFERENCES t1(a) ON UPDATE CASCADE) ENGINE=InnoDB;

# Cleanup

DROP TABLE t2, t1;

Before the change, the structures were allowed in MariaDB, but as MDEV-18114 describes, didn't work correctly.
Apparently the fix made them forbidden (as they were already, for example, in MySQL), but since I can't see clearly from the commit comment that it was intentional, I'll leave it to serg to confirm.

So, the end result is, if I understand correctly, that you cannot have a STORED computed column based on a field part of a foreign key defined with ON UPDATE CASCADE, right?

I guess that, if this is intended, we'd need to re-define all those virtual columns....

Sorry I pasted a wrong sample before, fixed now.

I do suppose that it was intentional, because the assumption is, if a user defines the virtual column and the foreign key this way, they expect them to work properly; so, if it's not possible, then the definition shouldn't be allowed. It is very unfortunate that it breaks the backward compatibility, we of course try to avoid it, but it's still better than to allow it produce erroneous results silently.

If it's due to foreign keys then yes, indeed, it is intentional. The way MariaDB works, and always did, foreign key cascading actions are applied to child tables on a very low level where the server cannot update STORED generated column values anymore. In other words, if a STORED generated column depends on a column that can be modified via a cascade action, this STORED column can become out of sync with other columns. Basically, it'll have an incorrect value. That's why such a table structure is no longer allowed.

We're planning to lift this restriction. MDEV-31942 (or MDEV-22361) when implemented, will allow us to recalculate STORED generated columns on UPDATE CASCADE and SET NULL actions.

Note that ON DELETE CASCADE is fine, it's allowed, because it doesn't modify individual columns, but deletes the complete row.