I did the following procedure:

1. Start Libreoffice 7.1.4.1

Version: 7.1.4.1 / LibreOffice Community
Build ID: f67b1ddedeb24fca1c5938e7cebfab73d708b35b
CPU threads: 12; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL

2. Create a new spreadsheet
3. Set Zoom to 310%
4. Save
5. Start Libreoffice 7.2

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 452bf1359dab3cfab9fd6007d68592e9c96382b3
CPU threads: 12; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-04_18:12:48
Calc: threaded

6. Open the spreadsheet I had saved in step 4
7. Observe that it was zoomed to 310% as expected

Colin, can you provide more detailed steps to reproduce your issue?

(In reply to Michael Warner from comment #1)

> 
> Colin, can you provide more detailed steps to reproduce your issue?

> Steps to Reproduce:
> Zoom calc sheets at different factors - Other User Parameters are also often
> corrupted. Following an update, verify the integrity of the user-defined
> parameters.

Perhaps it wasn't obvious -- "Sheets" was intended to imply the file has multiple sheets all set to different zoom levels.
My 5 sheets are zoomed 190, 310, 320, 280, 220 & 310

The latest update changed my Tools>Options>LibreOffice Calc>View> --Zoom [Synchronise sheets] from disabled to enabled.

It conceivable that swapping from one release to another to compare the effect is not causing the same disruption to user parameters as a physical version update.

As I intimated, I suspect the release code occasionally contains something that modifies the recipients' defaults to the coder's or tester's defaults. Other "User Settings" to be affected are stored sort lists where they go on the "missing list" and have to be recreated (now stored in a parametercontrol.ods safely filed away on the user account).
I've even had the toolbar preferences reset to standard release format rather than the user-defined preferences - but that's not quite such easy remediation.

Can not cofirm behavior, but that value should remain in user profile on version upgrade. 

The SID_SC_OPT_SYNCZOOM default setting [1] is 'true'. Do not beleive it will affect existing Spreadsheets and on toggle is applicable just when creating new shhets/documents.

Recorded to user profile (i.e. into registrymodifications.xcu):

<item oor:path="/org.openoffice.Office.Calc/Layout/Zoom"><prop oor:name="Synchronize" oor:op="fuse"><value>false</value></prop></item>

@Mike, is it feasible a routine release build upgrade would clobber this setting in user profile?

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Calc.xcs?r=a6e16476#607

(In reply to V Stuart Foote from comment #3)
> Can not cofirm behavior

Me too

> but that value should remain in user profile on version upgrade.

Definitely

> Do not beleive it will affect existing Spreadsheets and on toggle
> is applicable just when creating new shhets/documents.

True

> @Mike, is it feasible a routine release build upgrade would clobber this
> setting in user profile?

Upgrade will *never* touch any user profile; there's absolutely no code there that could (even in theory) do that.

However, theoretically it's possible that some *existing* data in the user profile could cause LibreOffice to consider the profile corrupt, and result in the profile's re-creation. Then I'd expect the value to revert to defaults, and for this setting, default is true, as you mentioned. Yet, this is not truly a problem of upgrade, but of the data in registry - and the only way to handle that would be to have either copy of the data that is considered invalid by newer versions (if it's in fact valid), or a scenario that generates that invalid data; and that is close to impossible (so far, we have ~zero bug reports with such kind of info).

I have been affected on a number of occasions.
The changes are never catastrophic - more of a pain in the derriere and once the impact is noted it's generally just a case of ascertaining where the user parameter is to be reset to the previous value.
It was originally more concerning when the "sort lists" disappeared leaving only the (6?) existing default settings - Not quite sure why I get the Israeli calendar though!
Is there a procedure I can run periodically to detect any potential corruption in my user profile - I assume when you refer to "file corruption" you are referring to something potentially identifiable by a chkdsk command as it's probably impossible to identify that something has changed a binary "true" to "false" without physical damage to the structure?

(In reply to Colin from comment #5)
> Is there a procedure I can run periodically to detect any potential
> corruption in my user profile - I assume when you refer to "file corruption"
> you are referring to something potentially identifiable by a chkdsk command
> as it's probably impossible to identify that something has changed a binary
> "true" to "false" without physical damage to the structure?

No, I refer not to a physical disk corruption (and so not to something identifiable by chkdsk), although such disc corruptions indeed could cause this (but such things would be not possible to fix in LibreOffice code, even in theory). What I am thinking about is some problem in LibreOffice (either in older version generating an invalid profile, or in newer version considering valid profiles as invalid). And this could only be identified by backing up the profile [1] from time to time, and especially before upgrading, so that if the problem appears, one could then try again with the profile restored from backup, check if restored backup also gets the setting "reset"; maybe check if older version still has the setting correct (downgrading the version); inspecting the setting in the profile before and after running the new version (to see if it changes) ... and finally filing the bug with the "good" profile attached, to allow devs to try and see what in the profile causes the problem (in the hope that it would also happen on others' system).

[1] https://wiki.documentfoundation.org/UserProfile

Most of my files contain URLs to other files or the internet. Could these have any impact upon the profile integrity?
Just as a side issue, I've observed that following my last upgrade, the load time for the first sheet of the day is quite noticeably slower than what had been perceived as normal.

(In reply to Colin from comment #7)
> Most of my files contain URLs to other files or the internet. Could these
> have any impact upon the profile integrity?
> Just as a side issue, I've observed that following my last upgrade, the load
> time for the first sheet of the day is quite noticeably slower than what had
> been perceived as normal.

Sorry, I'm aware it's a different issue, just needed guidance on whether it's reportable.

(In reply to Colin from comment #8)
> (In reply to Colin from comment #7)
> > Most of my files contain URLs to other files or the internet. Could these
> > have any impact upon the profile integrity?

In theory, just anything may affect integrity, if LO has a bug related to this specific piece. Hard to tell if URLs affect this specific case - it's better to not try to guess, but follow the backup-upgrade procedure and find out for sure.

> > Just as a side issue, I've observed that following my last upgrade, the load
> > time for the first sheet of the day is quite noticeably slower than what had
> > been perceived as normal.
> 
> Sorry, I'm aware it's a different issue, just needed guidance on whether
> it's reportable.

:-)

Yes it may be. Try with clean profile, measure start time of older and newer versions, report it. Definitely a separate thing :-)