I'm not sure if i have missed something in the documentation or i have some lingering transaction log being replayed causing this but here is what i have done. This is all with 3.5.0 community edition.
I first created a database by importing data (neo4j-admin import) and then created a bunch of indexes (through the cypher shell). This all worked as expected and I was testing the database successfully in various ways, the database being stopped and started many times.
I then wanted to try an alternate graph structure so on the same server i thought that i should just be able to modify the active database name in the config (stopping any server etc first). Create the new database by again importing the data using the CLI import tool (neo4j-admin or neo4j-import). At this point launching the console command it all came up ok, but i did notice when i tried to stop it later there was some error about not being able to rotate logs. However the main thing was i noticed it had gone and created the same number of indexes as my old database (based on the schema/index/native-btree-1.0 directory contents).
What I dont know is why these got recreated, apparently using the old definitions which are then broken because the graph nodes and relations has different properties amongst other changes. I've not found an explanation as to why they would be recreated nor anyway to stop it. I have tried removing the transaction log file from the configured directory and then removed the schema/index subdirectory, but i guess its possible the database now has the definitions baked in and is simply rebuilding them when started.
Looking in the old transaction log it seemed to contain what look like the definitions of the indexes so i assumed maybe it was replaying that bit for some reason. a) not sure why this was even here as i created the original database over a month ago and it was all ok as i previously mentioned b) why would it attempt to retry such old statements on a new database.
I'd love to hear from anyone that has a better understanding of what may have happened, and how to prevent this. I've assumed at this point having dug around that there is no other location some rogue definitions of the indexes could be hiding out. Clearly the database name isn't playing a role in determining what is going on.