Normal GPO definitions are stored inside the ADMX files and their translation in the corresponding ADML file. When updating your PolicyDefinitions folder or your central policy definitions store on Sysvol, you are able to create/define new GPO settings for the new OS. You could use older GPMC versions and things would basically work.
GPP are in total contrast to this behavior. They are hard-coded inside the GPMC. So to get these new settings and filtering options, you need to use the newest RSAT tools or the newest GPMC on the server OS. Unfortunately, it is not only, not seeing the new options when using an older GPMC, but you can seriously damage your GPO with GPP content when just opening it in an older GPMC.
When opening such a GPO with new GPP settings/item-level targeting in an outdated GPMC, the older GPMC does not recognize the new settings. So at best, you might not be able to see all the options. For example, you would not find an option to filter on Windows 10 or Windows Server 2016 families in older GPMCs.
At worst, the older GPMC can interpret the new settings as Corruption. Corrupted settings are automatically repaired/removed. This repair attempt can trigger the GPO was changed event and therefore trigger. So by just opening the GPO with GPP, you could accidentally remove settings without a notice/warning message. You would only notice an updated/higher revision number of your GPO.
So always edit/administer new GPP settings only with the newest GPMC of Windows 10/Server 2016. To prevent such problems in multi-OS environments, when not all GPO/GPP editing systems can be updated at once, you should mark your new GPO/GPPs with, for example, _W10 and open such _W10 files only with the newest GPMC.