It appears that this issue is no longer being worked on, so we are closing it for housekeeping purposes. If you believe the issue still exists, please open a new ticket after confirming it's present in the latest release.

Another fix could be in changing the behavior of the SELECT from a table created after START TRANSACTION WITH CONSISTENT SNAPSHOT was executed (second scenario).
Instead of returning ER_TABLE_DEF_CHANGED, we can return an empty row set, although I am not sure whether this is in accordance with the SQL standard.

For the first case with adding index while mysqldump is running (or in general case with any modification of the existing table structure via ALTER TABLE) there is not much we can do here.
START TRANSACTION WITH CONSISTENT SNAPSHOT was not designed to work with concurrent DDLs properly. The most InnoDB can do is to detect such cases and report ER_TABLE_DEF_CHANGED.

However, for the second case with new tables being added while mysqldump is executed there is one improvement we can implement.
It will not 100% eliminate ER_TABLE_DEF_CHANGED but may significantly decrease its probability.

Currently, inside 'dump_all_tables_in_db()' there is a loop through all the tables in the database

'getTableName()' is basically a call to 'mysql_fetch_row()' which fetches the next row from 'SHOW TABLES' whereas 'dump_table()' is a potentially long-running operation which reads all the data in a table and forms 'INSERT INTO' statements.

In other words, while long lasting 'dump_table()' is executed the chances that a new table is created by a concurrent connection are much higher. The worst part is that this new table may appear in the one of the subsequent calls to 'getTableName()'.
An improvement here can be in pre-fetching the whole list of tables before starting to execute 'dump_table()' for each of them.

From the mysqldump.c source code

Here is an MTR test case which simulates the scenario with CREATE TABLE t2 executed after mysqldump's START TRANSACTION WITH CONSISTENT SNAPSHOT.