These sound like very good changes. From a personal standpoint point, I’ve had to use betas a number of times to help customers solve bug issues, or sometimes testing new features, and later noticed some people seem to have forgotten they were still on the beta branch. So this seems like it could be useful. And also saves having to give players instruction's and reminding them about betas (opting in / out)

About the “Use Case: Preserving game saves”, does it means that for each game version we should keep a separated, dedicated branch?

What I like about this is that games who release "April Fools" versions (Or other Holiday Builds) can give players the opportunity to switch back them whenever they want to. ;P

Publicado originalmente por Kafumanto:

About the “Use Case: Preserving game saves”, does it means that for each game version we should keep a separated, dedicated branch?

No, that would likely be an overkill. You might consider it for some extreme cases, when the game changes too much, old saves are no longer compatible and you can’t somehow convert them to new version.

Publicado originalmente por dragon:

I also think this behavior is unclear at first and pretty annoying, I usually just end up switching my old build to default and going through 2fa before uploading the next beta. However I think this is because the branch functionality of the browser upload was tacked on later.

Open Builds, find the corresponding BuildID, select the default branch in "Set build live on branch" column and click "Preview Change".
It’s not programmer-style branches, they’re not for merging, Steam branches are simply named revisions (BuildIDs). So instead of merging branches you just need to set the same buildID live.

Publicado originalmente por StepS:

Great news!
However - is there still an upper limit to the number of coexisting beta branches, and if so, what is it today?

Oh wow, they’re rarely used in general, why would anyone want to spawn a lot of branches? Do you want to leave each previous version of the game in another branch for some reason?

Publicado originalmente por CA_OtherTom:

A very useful update. If we can just get the workshop to allow hosting of multiple mod versions tied to game versions - then my update nightmares will finally end.

That’s a nice idea, sounds like with these APIs it should be possible. Filtering out unbroken mods, for example for Don’t Starve Together, is indeed very frustrating.

Publicado originalmente por Maximumgame:

There should be an API to unlock a private beta with key in the sdk.

Agreed, seems like a weird omission why SetActiveBeta does not optionally support a password. Of course it won’t be secure, but it is not really already — anyone knowing the password can share it with someone else.

Publicado originalmente por StepS:

That's the thing - this news piece is implying that developers should more widely adopt the use of older-version branches for backwards compat.

Not should, that they may do it, and they now can make it more user-friendly if that was stopping them. It’s really quite a rare case in general, i don’t think i’ve ever seen more than 5 public branches, usually it’s 2-3.

Publicado originalmente por StepS:

I initially assumed that the APIs would allow to directly switch to a numbered public buildID, rather than a named pre-created branch, but the latter seems to be the case.

Well, that would be putting too much power to users — since they would be able to do or manipulate the code to do it. Branches is a more controllable approach, less mistakes possible from your side as well.
And hardcoding BuildID would be very inconvenient — using a branch allows you changing game files without touching corresponding code.

Publicado originalmente por StepS:

However, in practice, games that are under active support, receive several dozens of updates over their lifetime. If this new system is to be used as intended, then this limit needs to be greatly expanded. (I think last time it was capped at 30-32)

That’s only for breaking changes! When old savegames are completely unsupported or when new game version does not support achievements anymore or temporarily (seen one such case). Another case is when mods have changed too much, but they’re too valuable to just deprecate.
Do you really want users to access some previous buggy version just for the sake of it? And surely they’ll forget it’s not the newest public build and will come bugging you with old bugs.
So it’s always in your own interests keeping number of branches to a minimum.

Publicado originalmente por StepS:

This is on top of the space needed for development branches, which is shared with those public betas...

Space? What space? You can only have one branch downloaded via Steam client. (and that’s often to reason to create some dev-only internal AppIDs)
You can have several via steamcmd — but regular users would never do that.