I am not sure how we should communicate this, but the idea is that each channel is independent. That means, if you are on beta, just stay there and you will get the most stabe/tested updates. Likewise goes for experimental, if you stay on it, all works.
Generally, the canary will have the latest fixes and updates, but occasionally issues. Normally, you would be able to change from a canary to a beta, but for this release we had a short time window to warn Amazon Cloud Drive users. A problem was detected with the FTP provider in the canary, so we decided to delay all other changes than the warning, so even tough the version numbers increment, they do not follow each other.
This is a design decision, and we need to be able to run different channels so we do not delay or prevent updates to the canary while releasing a beta.
We could be more clear about the version numbers, such that they convey “newer than”. My idea with the number was to simply increment from 2.0.4.5, but 2.0.4.6 was taken, so I just went to the to the next number.
I could have used 2.0.4.6, but that would also be confusing as there would be two different builds with the same number but one with a canary tag and one with a beta tag.
You are the first person to request this information 
But I think you have a point. We should perhaps force increment the third value (i.e. we should be on 2.0.5.x for the canary and 2.0.4.x for the beta) to indicate database schema changes.
It has only been slightly problematic when people want to downgrade a canary, but here the problem occurs because you changed the update channel (or manually installed the beta).