Take a look at your wwwbatch.ini file, as the various wnt*() extender-based functions are pretty good at recording diagnostic information there when an underlying Win32 API function call fails.
If I'm understanding things correctly, wntAccessList() is able to identify these accounts as security principals to which permissions have been assigned on the specified files, and the account names are returned in a delimited list. However, calls to wntAccessGet() for these account names results in an error which means that the account name couldn't be translated into a SID value. If that's the case, then the underlying Win32 API functions used to convert between SID and account names are most likely failing to "round trip", with LookupAccountSidW() being able to take the SID value from an ACE in the DACL and convert it to "APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES", but then, later, a call to LookupAccountNameW() fails convert that fully-qualified account name into a SID value.
IIRC, there's code buried down inside the Win32 Network Extender that deals with this type of issue since there are certain well-known domain names that get returned when converting a SID to an account name that cannot be present when attempting to convert an account name back to a SID value. If the problem is what I think it is, though, then "APPLICATION PACKAGE AUTHORITY" is also another one of those types of well-known domain names.
To test that theory, try calling wntAccessGet() for those accounts, but trim off the pseudo-domain prefix up to and including the '\' character, such that you only try to get the assigned permissions for "ALL RESTRICTED APPLICATION PACKAGES" and "ALL APPLICATION PACKAGES". If that is successful, then you'll have to test for the presence of the well-known domain prefix "APPLICATION PACKAGE AUTHORITY\" and remove it from the values returned by wntAccessList() before making calls to wntAccessGet().
If this proves to be the case, then, long term, the Win32 NetWork extender may need to have some slight modifications made to it w/respect to the internal methods it uses for performing translations between SID values and account names so that the problem can be silently dealt with and prevented from happening regardless of whether or not you pass in the account name with or without that particular well-known domain prefix on it.
I checked the wwwbatch.ini and there was indeed a message about not being able to resolve a SID, so my next test will be to detect these particular groups and substitute the SID for them. Truncating the names did not work as the call then barfed. The one problem with this logfile is that there is no date or timestamp showing when an operating was logged, and clearly some entries in there are from a different project entirely. If there is still time in the development process, that's one limitation I would like to see fixed before retirement!