Hey @jsmolka - usually candidate is the right choice and regressions are very rare.
However sometimes those happen, my apology for this. Issues like this usually happen in area were our automatic testing is insufficient and for this class of problems we are now writing a new test that ensures that the snapd-xdg-open launcher works correctly all the time (it will be run as part of each of our code changes).
I think this also highlights that we should look into an idea from @niemeyer to de-couple core filesystem builds from snapd core builds. So that we can “snapshot” the core filesystem for 2.27 and only apply fixes to snapd without filesystem changes. We will definitely look into this as another way to fix issues like this.
As for your question about going to beta - it is probably safer to stay on candidate and I expect the updated core in beta to reach candidate soon (once our internal QA finished).
The update may not work right away because there may be an old mount namespace hanging around (@zyga can provide more details on this). A workaround is to
sudo umount /run/snapd/ns/test-snapd-tools.mnt
where test-snapd-tools.mnt is the name of your snap (or reboot but that is a bit heavy handed 
. But hopefully @zyga can provide more details about this.
