@jomaule
Just to give you a bit of background, I have been lucky to have worked extensively with iOS and macOS management in both business and education deployments, starting back when management solutions first emerged in 2014 / 15 as just Apple Configurator and Profile Manager, then with MDM's as they started to emerge (Mainly Jamf at the time). I also interned at Meraki support at one point, and naturally loved working on Systems Manager issues, so I have a bit of knowledge specific to SM.
MDM's just build on top of Apple's API's for managing devices, and are at the mercy of Apple, so I wouldn't suggest switching to an entirely different solution just from this issue. If Meraki is saying the issue is on Apple's end, it is highly likely they are accurately telling the truth, and the issue would be the same for any MDM solution. There are a lot of quirks that Apple has in the management system, especially with things like this involving locked devices and pushing commands, that Meraki has to contact Apple about, submit cases, provide evidence, much like you have to do with Meraki.
Still, I would think that if the devices are supervised, and enrolled in DEP, that the updates would push no matter what after you send the command next time the device is unlocked. DEP and supervision are supposed to provide complete remote control over everything requiring no interaction from the user.
With the wide range of iOS versions, if those devices are stuck at iOS 11 as their max version, you should consider phasing those out of active use if you are deploying Apps that required higher versions for their most recent updates (Swift playgrounds). Also, as a side note, iOS updates can sometimes resolve MDM quirks.
Double check that the "Delay OS software updates" option is not set under the restrictions payload on any of your profiles. Don't know if that would actually be effecting all this, but it's there, and sounds like it might, so worth a check.
But this may be a quirk. Assuming it is, if you send the clear passcode command, and have a profile configured to enforce a passcode on the device, it will clear the passcode, then next time the user uses the device, they will be given a message to enter a new one, and will have to do so within an hour, after which it should force them to. I just tested that with an iPhone on my end to be sure.
As for the deployment to the wide range of ages, and the difficulty of potentially needing to have them set up a new passcode, however you first got the students set up with the passwords will likely be your best bet for doing this. Maybe doing this on a school day, making it an event and calling it "iPad Day" or something to make sure everyone is prepared, and going class by class to get things done?
Again, this really shouldn't all be required. I couldn't tell you why, but I have seen issues like this specifically with pushing app updates from time to time. There is usually some magic fix or settings change that will resolve the issue for the most part.
Two other thoughts how to fix this that I would recommend testing on a single device that is behaving this way to see if they work for you as that magic fix.
1. Send the delete app command from Dashboard. Then reinstall the latest version. This might delete the user data associated with the app, so again you would need to test this method to make sure it works for your deployment environment.
2. Assuming you have the SM app installed this may work for either, or both issues (OS and App updates). First send the OS or App update command. Then go to your device list under Monitor -> Devices, and send a notification to all the devices needing the update, or just all of the devices. The notification will cause the device to wake up to display the notification, which might then cause the command that wasn't going through before to successfully go through. As all the changes should be using Apples APN service to send commands, I don't know why this workaround sometimes solves things, but I have seen it work when OS commands aren't successful, that going through the SM App notifications to wake up the device solve the problem. If that way doesn't work, try doing the same thing, but sending the notification first then the update command. Just for the heck of it.
