The short answer is yes you should be able to hide (or gray out) updates unless their prerequisites are in place -- a needed update is installed or a particular file version is already installed. It will likely require a bit of investigation on your part to pick the most reliable details with these large rollups but it should be doable to hide or better gray out an update if it needs last months rollup to be in place first.

BTW, the dates also act to install updates in order if multiple updates can be run one after the other -- the older dates go first so 20170901 goes first, 20170902 next, 20170903 will run last - kinda cool.

TheApGuy will have more specific details I'm sure, I don't know how much of the old functionality has been changed or removed but you can have a look at the old docs here -->> viewtopic.php?f=27&t=1277&start=20#p5539

I'm aware that Autopatcher currently installs in date order, it's down to users visually seeing the unneeded install within the GUI selection, if a user already has a superseded update installed, the previous update would still show as installable within Autopatcher.

But what actually happens in the background is it silently fails (some generic error like this update is not applicable to your system, which a user wouldn't see with the update running through the /quiet switch) to install as there's a newer cumulative version installed, but the user is stuck in a constant loop everytime Autopatcher Is run that it's available for selection to install again

The most reliable data for me would be the minor build version itself as this wouldn't change until a newer update is installed in this case.

I noticed on a forum that the update I'm having issues with isn't compatible with Windows 10 Home, it might be the rare instance that I just need a way for it to show to non home edition users only

Not sure if this can be done with the current version of Autopatcher, by adding in the checks for greater and less builds, same builds or show just to home or pro users would give me more flexibility for these rare occasions

It would be up to TheAPGuy if it's something he can do or consider doing, not sure of Autopatchers capabilities or possible drawbacks

Maybe using something like the greater or less than suggestions to "manage" the Cumulative Update aspect of things, and the other stuff like flash player update is more relaxed like it currently is now

Any system that has it installed "should" be installed at this location.
C:\Windows\System32\mrt.exe <-- this will get you a file version as well as install date. We don't detect it this way though... we do it with the registry...

Give your apm a different unique name since the current one for this is
UniqueID=KB890830_X64
So call yours "UniqueID=KB890830_X64_winX" or something like that. We don't want them colliding in the update tree generation section.

I have just looked around and it "seems" that the only way to check windows 10 minor build is to actually check registry.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR = 0x000006b3 = 1715

Hmm Yes I can do something similar to that... hold on.
edit: hmm found an interesting old way to detect pro/home version. testing
Late edit:
Ok so I got something here for you to try on your different version of windows 10s. It "should" detect the pro or home status via reading OperatingSystemSKU from WMI. Old way is kinda silly so hoping the new way is better.

Read the text file this program generates. You should see PRO or Home or not in the tag line.
Here is mine
TEN|TEN_X64|TEN_SP0|TEN_SP0_X64|TEN_PRO|TEN_PRO_X64|TEN_PRO_SP0|TEN_PRO_SP0_X64|TEN_|TEN__X64|TEN__SP0|TEN__SP0_X64|TEN__PRO|TEN__PRO_X64|TEN__PRO_SP0|TEN__PRO_SP0_X64|TEN_BN14393PRO|TEN_X64_BN14393PRO|TEN_SP0_BN14393PRO

It seems to be detecting things fine in regards to (English (1033) Microsoft Windows 10 Home X64 (10.0.10240)
Architecture: X64), although I have noticed in the tags (|TEN_SP0_BN10240 etc) that it's missing the home or pro status

Not sure if this is a bug specific only to build 10240 version 1511 or everything in general until I can get on my laptop at home and test further

It maybe the way you have programmed it, so you use the normal BN10240 for a home install and BN14393PRO for pro

Just quoting what I see as I'm not sure if there should be 3 instances, a normal to accept updates for both, then 2 singles for each type home or pro

If it should be 3 separate types, in my instance it's not flagging up I have home installed on this current laptop

OS SKU 101 hmm... that is... not listed in my reference chart. Ohh I see. The chart has not been updated in a good while so... ya. There are even higher numbers then 71 now. Time to add a few new definitions to the chart.