A lot of people cares about build 18356.16 because a bug in this build stoping 18362.1 from pushing it to Release Preview ring
But if people were give up about update IP build like this to 18362, we were got RTM two weeks ago. Why to update old IP build to 18362 ? It has time bomb.
In short: it doesn't matter that you think that build 18356.16 should be ignored or forgotten. What matter is how Microsoft pushes builds through Fast/Slow/Release Preview rings. So, if people from Slow ring can't update build 18356.16 to 18362.1, then Microsoft will not push 18362.1 to Release Preview ring.
And won't push it to RTM/Production either. There's no harm in waiting a little longer. 18362.1 will still be the final 19H1 build anyway
I'm marginally anxious only because I'm "the deployment person" at work and since we're on the consumer upgrade path (no Ent or LTSx) I want to get the next version on new deployments as fast as possible to avoid those users having to sit through the upgrade. Otherwise, not frantic for it, but will happily upgrade once it's available. 1809 has been swell for me and I don't see myself using the light mode.
I wonder if this is a reasonable way to go. I mean, I don't do deployments anymore, but if I was on semi-annual channel I would always try to stay one version behind because that means you're on a release that has been serviced for some time through cumulative updates, and that makes it more reliable and stable IMO. With a new release, it's like jumping in cold water. You don't know what issues may arise and you may get into a lot of trouble solving problems. A few years ago, admins cringed at the thought to install the latest Windows release when it just came out, and they had a point in that it wasn't that urgent to update and a lot safer to wait until the first service pack came out. In my experience, a three-year release cycle would be optimal for business, but Microsoft obviously decided it's not. So now we got all that fragmented mess.
According to the April 2. update of the 18356.x announcement, it probably takes a few days before they roll out 18362.1 in the slow ring for 18356.21 users in slow, let's see what happens then
We do pay for it sometimes. 1511 was particularly troublesome because the hardware-based disk encryption component of Bitlocker was messed up and was wrecking installations. However, we decided from the initial development of a deployment strategy to "bend like a reed in the wind" and just stay on whatever consumer upgrade path MS (and Apple, we use both) set up. It is less work to verify our apps will work with future revs than to dawdle with old releases on some arbitrary timeline.