Isn't it the same in InnoDB and elsewhere? The engine always supports lz4 (and all other compressions can be possibly enabled at compile time). But you'll get an error when you're actually trying to use it if you don't have the provider loaded.

Isn't it the same in InnoDB and elsewhere?

No, but the exact analogy doesn't work here. It is a variable for Mroonga, but it is a status value for InnoDB.

MariaDB [test]> show variables like '%lz4%';

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

| Variable_name                  | Value |

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

| mroonga_libgroonga_support_lz4 | ON    |

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

1 row in set (0.002 sec)

MariaDB [test]> show status like '%lz4%';

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

| Variable_name   | Value |

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

| Innodb_have_lz4 | OFF   |

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

1 row in set (0.002 sec)

MariaDB [test]> install soname 'provider_lz4';

Query OK, 0 rows affected (0.026 sec)

MariaDB [test]> show status like '%lz4%';

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

| Variable_name   | Value |

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

| Innodb_have_lz4 | ON    |

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

1 row in set (0.002 sec)

The engine always supports lz4 (and all other compressions can be possibly enabled at compile time)

Do you mean it as an intended change in 10.7?
It wasn't the case before, as the description tries to explain. In 10.6 the value of the variable depended on whether lz4 was available at compile time or not. On systems where it wasn't, it was set to OFF.
Now even on the same systems where lz4 is still not available it is set to ON.
If it's an intended change, then okay. I surely don't think it is critical (the priority value is a technicality), and documentation for the variable needs to be adjusted anyway.

It's a read-only variable. Basically, it serves a purpose of showing the status, whether mroonga knows about lz4, although, technically a user can turn an existing support OFF.

What was changed is its default value. Yes, it was an intended change. Mroonga now always supports lz4 internally. If one loads a provider plugin, mroonga will use it.

For the record, the variable is not just informational, it also changes the behavior of CREATE. I tried to indicate it in the description, but it turned out inaccurate. Here is another attempt.

* same regardless whether provider_lz4 is not installed or it had never been built for the system

The bold outcomes above indicate behavior with the default value of the variable, and red indicates a change. It is not a great change, as it goes like this:

MariaDB [test]> create table t1 (a int, b text COMMENT 'FLAGS "COLUMN_SCALAR|COMPRESS_LZ4"') engine=Mroonga;

Query OK, 0 rows affected (0.099 sec)

MariaDB [test]> insert into t1 values (1,'foo');

Query OK, 1 row affected (0.001 sec)

MariaDB [test]> insert into t1 values (2,REPEAT('foo',1000));

ERROR 4183 (HY000): MariaDB tried to use the LZ4 compression, but its provider plugin is not loaded

However I don't think it's critical enough, so if it was intended, then so be it.

In general, judging by the results, I think that the variable was meant to be changed to non-default only one way, ON => OFF, to make the compression option be ignored. It was not expected to be changed from OFF to ON, and the result in this case was not good even before.
It also appears that there is no check for the presence of the compression algorithm upon table creation, Mroonga merely checks the value of the variable. If it's OFF, table creation causes a warning and the compression option is ignored, otherwise it succeeds.
The presence of the compression algorithm only becomes important when a long enough value is inserted into the table.