Chord name not recognised

This would normally be due to an incorrect installation. Did you do something unusual when you extracted the files from the zip file? What OS are you using? On Windows, running a nightly build also displays a terminal window. Do you see an error about not being able to load a chord list? If so, what is the pathname? Is in in your nightly installation directory or somewhere else?

This is related, I guess: I compiled that version from sources, and when launching it from Qt Creator is says: Debug: ChordList::read failed: <[path to git cloned repo]/build-qtc/styles/chords_std.xml> although I successfully added a SoundFont file to [path to win-user documents]/MusescoreDevelopment/SoundFonts.
Maybe the development version isn't using the preferences to find that file?

Probably related, indeed. I assume you are on Windows. What you describe is *definitely* the result of an incorrect installation. When building from sources, after the initial make, you then have to do a *second* make with "install" as the target. This is what copies the chord files as well as the soundfonts to the proper locations. And then instead of trying to run mscore.exe from the build.qtc folder, you have to run it from the win32install folder that was created at the "make install" step. On Windows, MuseScore uses the folder you actually invoked it from to find its other files. So running it from build.qtc won't work - it has to be from win32install. Otherwise, you see exactly the symptoms you describe - missing soundfont and chord files, probably other issues too.

Since you are apparently using QT Creator, this means you need to set up custom deploy and run steps to do this for you. Because all of this is non-obvious and I had to rediscover it all on my own a few weeks ago, I updated the compilation instructions for Windows to explain it. So you might want to take another look at those instructions - the part at the end about QT Creator - to see exactly what you need to do.

Niw, in the case of nightly builds, all of this *is* done correctly. So assuming you simply extract the entire contents of the zip file and run the executable from that location, everything should work, and I've verified on Windows at least that the particular nightly build in question is fine.