Invisible columns are columns created by the user that have the INVISIBLE attribute.

If you write

CREATE TABLE test_2(id INT NOT NULL, UNIQUE INDEX(id)) WITH SYSTEM VERSIONING;

you don't create any invisible columns, the table test_2 won't have any. "row_start" and "row_end" aren't invisible columns, they're basically internal properties that every row has. They can be selected, but that's it.

The fact that some I_S tables show them as columns and others don't is, indeed, inconsistent.

Referring (once again) to my comment in the original MDEV-14785.
Please note that hiding internal system versioning columns from STATISTICS / SHOW INDEX alone won't bring the desired consistency, but it will make problem analysis harder.
EITS and InnoDB statistics (both of which are unrelated to INFORMATION_SCHEMA.STATISTICS table, an unfortunate name clash) are still collected for versioning columns, so they will still show up in corresponding column_stats and index_stats tables, thus inconsistency will remain.
At the same time, errors like this

MariaDB [test]> set system_versioning_alter_history= KEEP;

Query OK, 0 rows affected (0.000 sec)

MariaDB [test]> create table t (pk int primary key, a int) with system versioning;

Query OK, 0 rows affected (0.055 sec)

MariaDB [test]> alter table t drop column pk;

ERROR 1072 (42000): Key column 'pk' doesn't exist in table

will become even more confusing than they already are. Now the user can at least run show index and get some hints from it

MariaDB [test]> show index in t;

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

| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |

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

| t     |          0 | PRIMARY  |            1 | pk          | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |

| t     |          0 | PRIMARY  |            2 | row_end     | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |

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

2 rows in set (0.001 sec)

but if we lose this second record and it will only show pk, then there will be no explanation whatsoever why DROP COLUMN fails.

There are probably more cases when system versioning "internal properties" interfere with operations unrelated to versioning. While it is so, I think hiding them completely might do more harm than good to the end users.