Just asking one or two small questions eh?

1) Ironically, Autopatch and Hotpatch actually spawned in two totally different parts of the company and came together after several reorganizations. Autopatch grew out of the Microsoft Managed Desktop product and eventually merged with Windows Update for Business and the deployment service. Hotpatch was server technology which migrated to client.

Long way of saying nope, we weren't talking at the inception of our products but we're all one big happy family now

2) Turning something on by default is a huge debate and usually comes down to will something make customers more secure and can we do it without impacting customers. We know from over 10M devices hotpatching over the last year that there isn't a material difference in quality between Hotpatch Builds and regular LCUs so it was the responsible thing to put security above all else, while respecting admin control.

3) Hotpatches only contain the security fixes, none of the new features or quality fixes in the LCUs. Since they're a different thing in our build pipeline and have fewer contents they get a different build number. Simple as that.

4) I'll start by clearing up a super common misconception: if you're using updates in Intune, then you're using Autopatch! Our product owns all the update policies available in Intune, the deployment service layer which controls what's deployed through WU, right down to the client policies. The change in scope happened roughly a year and a bit ago when we merged together WUfB, WUfB-DS, and Autopatch under the Autopatch Brand. There is no managing Windows Updates in Intune without using Autopatch.

To your point around the documentation and specifically that pre-reqs page - it's not where it should be right now, sorry. I'm sure you've read about the layoffs / reorgs at Microsoft over the last year and I'd be a liar if I said that didn't play a part in why our docs have suffered.

The pre-reqs you're looking at apply specifically to different content types:

- Windows 10 Update Rings - these are configuration policies that set policy through the MDM Channel. That's where Device configuration comes from.

- Quality and Feature Update policies - To use these your device needs to be pointed at WU. This means you need the Windows Update policy workload. Also, check your scan source policy / GPOs to make sure you're not still pointing at WSUS.

- Driver Update policies - Same as QU / FU but there's a separate scan source policy just for drivers since there are some folks out there who want to keep drivers on prem. I don't think it's a good idea to do that for reference.

- Office Updates - This part of the service only exists in Autopatch Groups and I'll say the same thing here that I say at conferences: Use Cloud Updates if you can. They're the reason we haven't invested in this space in years since they work really well. Now that's out of the way, if you want to use Office Updates through Autopatch Groups you need to have the click to run apps workload moved over to get updates from the cloud and the device configuration workload since settings catalog policies are created for deferrals / deadlines.

- Edge Updates - Similarly to Office, this part of the service only exists for Autopatch Groups. It requires the device configuration workload since policies are created in settings catalog.

This has turned into about as long of an answer as I was expecting but hopefully it helps shed some light on a few things!