[Android Software Development] pndwal:
Yup, this removal of GMS processes from DenyList has occurred since USNF moved from Riru to Zygisk injection for Magisk 24+, and the function only really exists because users began adding DroidGuard ('safetynet') + main GMS (Google Play Services) processes to new DenyList manually (old MagiskHide used to add these automatically to its HideList for the same purpose) for Riru based USNF, which became necessary with the removal of MagiskHide... Seems it was easier to remove the processes for Zygisk based USNF than to remind users to remove them/not to manually add them anymore. 🙄🤷‍♂️

The reason for Zygisk based USNF removal of GMS processes from DenyList at reboot was that USNF then began integrating its own targeted root hiding for DroidGuard + main GMS process since proper hiding modules didn't exist and including GMS processes in denylist kills main USNF functions since module modifications including its code injection into GMS are reverted by DenyList functions... Later, removal was made to occur only when DenyList was enforced (@ipdev committed) since proper hiding modules like Shamiko (borrows denylist but implements hidelist mode which doesn't deny/revert Magisk modifications) don't cause this issue... When DenyList is enforced, USNF is broken until reboot, which is when removal of GMS processes occurs...

@chiteroman's PIF module was originally a fork of USNF so behaviour was exactly the same... Now, however, it's commit history has been removed several times and code re-written (@osm0sis says it was completely rewritten, buy I wonder if much of it is still identical; at least portions of script I've checked look unchanged) which means it's no longer technically an USNF fork, as @osm0sis has been at pains to point out. However it seems that the denylist-removal behaviour (user protection) is still much the same if not identical...

@chiteroman's PIF module was originally a fork of USNF so behaviour was exactly the same... Since then it's commit history has been removed several times and @osm0sis has confirmed that the code has been re-written completely which means it is no longer a USNF fork. However some functionality is governed by Magisk module scripts and he has also confirmed that these were lifted directly from USNF having had only minor changes since, so installation and boot functions such as global setting of 'sensitive' props to safe values, GMS denylist-removal (for user protection) behaviour etc remains substantially the same as in USNF.

FWIW, I think this 'protection' was never really necessary; if users had manually added GMS processes in DenyList, this was enforced and USNF failed, I feel it would have been better that they'd worked out the issue and removed the processes themselves per changelog/release notes rather than being protected from their unwillingness to read such notes... Lack of understanding is the only reason why current PIF users would manually add these processes in DenyList where it's enforced also...

Nb. There have been 'edge' cases where adding GMS processes in DenyList has served a purpose, eg. w/ Shamiko using list as hidelist (ie. with DenyList disabled), an added function to prevent font modules from breaking system UI could be made to work... I believe later font modules now include fixes for this anyway...

🤠 PW