Hence I mark this as a bug NOT related to reduced lock.

Wohoo(for now :)) I repeated the same bug with lock-ddl=ON;

Steps to reproduce:

1. ensure server has two undo tablespaces as shown below:
   
   

2. take full backup

3. now drop both of them
   
   

4. restart server

5. this create two undo tablespaces in this ORDER undo_2 first and then undo_1 (and make undo_1 inactive)
   
   

6. now take incremental backup as inc1

7. now create additional undo tablespaces with the intention to generate page delta on undo_2. So do some transaction and keep them open. also I disable the other undo tablespaces so that undo_2 gets used.
   
   

8. take incremental backup again inc2.

9. Prepare full → no issues

10. prepare inc1 → an error message seen as below:
    
    

11. prepare inc2:
    
    

another example how space_ids are reused. I swapped the creation order after restart

it looks like innodb_init is the normal init to do redo apply.. (after the deltas applied)

Some more info on sequence:
1. full contains

2. inc1 contains und002.ibu
   
   

3. inc1 also sees undo_001.ibu with different space_id.
   
   

4. so inc1 will rename undo_001.ibu to tmp_4294967277.ibu

5. then when it processes undo_002.ibu.meta, it sees that undo_002.ibu is not present and it tries to create with space_id 4294967277

6. but fil_cache already has spaceid 4294967277 with tmp_4294967277.ibu name. it is still a conflict and it errors out. doesn’t create undo_002.ibu at all

7. inc2 has
   
   

8. this time because 4294967277 is renamed in previous iteration, undo_002.ibu is created again and it will be successful. This is an empty ibd/ibu file

9. the end I think, innodb init is called (hmm, apply-log-only isn't called ?) and this rouge/bad undo_002.ibu causes the crash!