Tablespace relocation broken misfeature or spurious test

The MTR test innodb_zip.restart exercises the following scenario:

• CREATE TABLE without DATA DIRECTORY clause,
• shut down the server,
• Move the .ibd file to a different directory, outside the normal data directory,
• Manually create a .isl file for that table with the path to the {{.ibd} file,
• Start the server,
• Expect the table to find its data as if it was creates with a DATA DIRECTORY clause.

This scenario is not documented anywhere in MariaDB documentation. According to general principles, it should not be legal, i.e. outside of documented test cases making manual changes to data directory has no guarantee of working, and there should be no expectation of it working correctly, and if it happens to work for some case, no expectation of continuing to work in subsequent versions.

The test scenario was merged from MySQL 5.6 in 2012. It appears the support there for such scenario was intentional: although it's not documented in MySQL 5.6 Reference Manual either, it seems to come from a WL and is specifically referenced in the commit message that introduced it.

Even if the scenario was to be considered a feature, the way it's implemented would not be correct. The table's metadata, persisted in information_schema.innodb_sys_tables, uses the DATA_DIR flag to mark tables which have a DATA DIRECTORY clause, which is not affected by manually adding the .isl file. The code that makes this scenario work flips the flag in the in-memory version of the metadata, but not the on-disk version, which causes the server to misbehave in a number of scenarios. One example is DROP TABLE leaves the .isl file behind, which causes an error when trying to create another table with a DATA DIRECTORY clause with the same name.

To "fix" this a decision needs to be made whether the scenario is a supported feature, or something that accidentally works and accidentally has a test that tests it.

If it's a feature, it should be documented and the data inconsistency fixed.

If it's not a feature, the test should be removed.

Or do we want to keep in as an undocumented "semi-feature", where we keep supporting the scenario and keep the test against it, but don't fix the problems with it because it's not actually a supported behaviour?