If the complaint is only about "silent corruption", let's fix it in 10.2 by making it not silent — namely, issuing a warning at the end that the corruption might have happened if --no-locks was used and MYI/MYD/frm/Aria mtimes was anywhere after the backup start time. It'll keep --no-locks useful in 10.2 for most use cases (InnoDB only, privilege tables are rarely modified).

And --no-locks can be removed eventually, when a better solution is implemented.

--no-locks is not recommended, so people who use it, will know it. They (people who know it) would not use any MyISAM or Aria either. That much is also stated in the documentation for both upstream xtrabackup, and our product.

Removing something because it is dangerous, without offering an alternative, does not really work.

Now, lock-ddl-per-table is mostly harmless, it is not default, and offers some advantages compared to DDL tracking - namely that there is no need to copy changed files into backup again.
I'd say, we'll keep it, and with that, I think we can close this bug.