If changing an index from (a,b) to (a,b,c) for example, it is important that the new index is created before the old index is dropped. Otherwise, while the index is being created, queries for (a) or (a,b) will not have an index to use. This is even more critical if an index creation fails for some reason, and the database is left without the index until a fix might be developed.
forge:db/4843
I added a test for this command since there wasn't one before, but I couldn't think of an effective way to mock the ensure/drop index calls and validate the order in which they were called.
Re-opening due to the issues with unique index changes we discussed.