Yes, the issue has been reported to our Content Provider.

Work-Around is don't put it into a policy and deploy it stand-alone.  (Sorry not great answer).

Hopefully our provider will get the June SSU fixed sooner rather than later.

Thanks for the prompt response!

Assuming they do fix this, most likely by releasing an updated version of this patch to their availability channels, do you know what behavior I can expect to see on my end?

One possibility would be that they would just have the new patch supersede this one; that would mean I'd have two patches with the same apparent name, release date, and contents, one of which supersedes the other, which wouldn't be ideal.

Another would be that they would just update the canonical version of this patch. In that case, one of two things might happen: either I'd see the new version show up in my patch feed, near-seamlessly replacing the one I already have, or nothing would seem to happen on my end at all, and I'd have to take separate/special action to get the new patch to show up - most likely, deleting the existing patch and running a "check for available patches" action.

I imagine that there might be other possibilities I'm not thinking of.

to be more specific, use the remediation wizard to create the standalone deployment.  the reboot only occurs when there is more than one patch (example patch policy) because the ssu doesn't chain.  

sometimes the do just replace content with blind rev.  since the vendor does the official supserseding it's unusual that they would supersed it but it's possible. asssuming it's a blind rev you would need to re-cache if/when it gets fixed/

We got a fix to the issue.  I have confirmed that the content was replaced but not yet tested the install due to not having a Windows 10 that is applicable available to me.  However if your would like to confirm the fix before I’m able to get to it:

1. Update the subscription – this should have happened as the nightly schedule will have run, but if for any reason the service was disabled or server down, just make sure you update subscription.
2. You can confirm in database query that the patch content has changed by running this query:
   select * from patchsignature where name like '%KB5003974%';
3. In the above query the two patches should now have the following MD5 values:
   8403a5a7b567b752b8cd387691d68286 "2021-06 Servicing Stack Update for Windows 10 Version 1909 x64 (KB5003974)"
   ddc19ec3c3a835c95b6650acdafba116 "2021-06 Servicing Stack Update for Windows 10 Version 1909 for x86 -based Systems (KB5003974)"
4. Run the Discover Available Updates (DAU) on the test device or let it run on schedule.
5. You can confirm that the newer plr is on the workstation by running this:
   CertUtil -hashfile "2021-06 Servicing Stack Update for Windows 10 Version 1909 x64 (KB5003974).pls" MD5
   result should be:
   MD5 hash of 2021-06 Servicing Stack Update for Windows 10 Version 1909 x64 (KB5003974).pls: 8403a5a7b567b752b8cd387691d68286
6. Bring up the patch in ZCC and select Action / Update Cache.  This is necessary to rebuild the patch bundle with the latest files.
7. Use the deployment wizard to deploy the patch to the test workstation.  This shouldn’t reboot the device since it runs standalone even with the problem.  But in this case when you look at the event log for WSH event you should see the /norestart on the install command line.