I have noticed two S_DEVELOP related checks which were recently introduced to the standard system, but you need to consider that they might create some confusion if you have restricted S_DEVELOP appropriately..
1) [SAP Note 1012066|https://service.sap.com/sap/support/notes/1012066] introduced an ACTVT '16' for S_DEVELOP to distinguish between displaying programs from workbench transactions and executing them. This does not impact SA38 and report trees and background jobs.
Gotcha: Some RFC scenarios schedule the job in the target system, to then make the RFC calls back to the original calling system. This can sometimes be usefull as the calling system (often a BW system...) can then determine when the communication system starts the processing and pushes the data back again to the BW, instead of the BW always pulling extraction of data. Depending on how the call is made, these new ACTVT '16' checks will appear for the RFC connection users, who should ideally not have any S_DEVELOP authorizations.
Solution: The new S_DEVELOP check gives you the option to control the object type as well as the object name, so it is not all bad... Otherwise, change the programs to use the JOB* function modules which are the APIs for SM36.
2) [SAP Note 1594110|https://service.sap.com/sap/support/notes/1594110] corrected missing authority-checks in function modules which are remote enabled but typically called locally.
Gotcha: Some F1 field information dialogs call function modules in new tasks and these are dependent on config, for example, which determines the function module name. End users sometimes use this. The calling application needs to get the current interface definition of the function module (it does not rely on it being stable it seems...). However these F1 function modules are in the same function group as the problematic ones which were corrected, and a check was introduced which is too strict (ability to display function modules to be able to call F1 technical information dialogs).
Solution: [SAP Note 1487329|https://service.sap.com/sap/support/notes/1487329] removes the checks again from the "harmless" function modules in the same function group. As a workaround you can assign display '03' access to S_DEVELOP object type FUGR and PROG and be very carefull of transaction authorizations for the endusers. Do NOT assign ACTVT '16' for object type 'FUGR' as this is equivalent to SAP_ALL and you have little chance of restricting the local function groups which need to be displayed...
Both of these two new checks can create considerable havoc for your users depending on whether you use the features and have restricted their access sufficiently.
See the documentation on object S_DEVELOP in transaction SU21...