In SQL Server, this is handled by setting a DEFAULT value when adding (or altering) a new NOT NULL column, which is then applied to the history. See https://docs.microsoft.com/en-us/sql/relational-databases/tables/changing-the-schema-of-a-system-versioned-temporal-table?view=sql-server-ver15

But this doesn't appear to work in MariaDB. Unsure what the standard says, The standard does not permit ALTER statements to versioned tables, but it seems like it would be a useful enhancement. And the current, inconsistent behaviour is clearly a bug.

In the meantime I will document this limitation explicitly.

Doesn't look like a bug to me. In the examples 1 and 2 you have a column with (historical) NULL values, and your ALTER converts it to NOT NULL. This causes "1265: Data truncated for column 'b'".

Compare with

CREATE TABLE abc (a INT NOT NULL);

INSERT INTO abc(a) VALUES (1), (2), (3);

ALTER TABLE abc ADD COLUMN b TEXT;

ALTER TABLE abc CHANGE COLUMN b b TEXT NOT NULL;

No system versioning. Same error.

In your third example you add a NOT NULL column, so you don't convert NULL values to not null.

@Sergei I see. In your parallel example on normal tables at least I have to option to update rows in between the two ALTER TABLE statements so as to supply sensible values. Has MariaDB planned to enable updating historical rows so as to supply sensible values?

No, so far we only planned to allow INSERT's for mysqldump to work.
The easiest workaround in your case would be to set sql_mode='' for the duration of the last ALTER.
Like

SET STATEMENT sql_mode='' FOR ALTER TABLE abc CHANGE COLUMN b b TEXT NOT NULL;

this will make NULL-to-empty-string conversion a warning, but not an error.

What should I do if I wanted a more sophisticated historical value in a new column? E.g. a historically valid foreign key or some other sensible expression?

It is natural for data models to evolve over time and so is the practice of updating rows for a column that did not exist previously.

Example 1:
Imagine you're a business located in country A and have a table customer_addresses.
You don't store a country in the table, because all your customers are located in country A. Then one day, you decide to expand the business to a neighbouring country B. Preparing to expand to country B, you add a new column customer_address.country. You update the customer_addresses table so that all countries are filled with A. Now you would also like to update historical rows, but you can't.

Example 2:
Imagine the same table of customer_addresses. It has a country column. This is a textual column. Then one day, you decide to normalize your model. You move the textual values into a separate table called 'countries'. The column that was previously customer_addresses.country is replaced by a column customer_addresses.country_id with a foreign key. You update the customer_addresses table so as to appropriately replace the previous textual column values with references. Now you would also like to update historical rows, but you can't.

You cannot successfully make your historical selections on the historical tables any longer, after these changes.

there's a workaround with two ALTER's. Something like (using your first example}

SET SESSION system_versioning_alter_history=KEEP;

CREATE TABLE t1 (a INT NOT NULL) WITH SYSTEM VERSIONING;

INSERT INTO t1(a) VALUES (1), (2), (3);

ALTER TABLE t1 ADD COLUMN b TEXT NULL;

UPDATE t1 SET b = 'value';

ALTER TABLE t1 ADD COLUMN b_new TEXT NOT NULL DEFAULT (COALESCE(b, "foo"));

ALTER TABLE t1 DROP COLUMN b, CHANGE COLUMN b_new b TEXT NOT NULL DEFAULT '';