ApexUserModeWithPermset Feedback

Dear Salesforce, please do not GA the ApexUserModeWithPermset feature. 

There's system mode.  There's user mode.  And the ApexUserModeWithPermset feature creates this murky, new in-between state that only adds confusion to the evolution in Apex security that has happened in recent years.

If the system knows what security is required (via PS Id) to execute a DB operation, then that seems to be a prime example of when system mode should be used.  I mean, the permissions currently assigned to the user certainly aren't being honored, rather the user permissions are being over-ridden and elevated, so to claim this is user mode is a bit disingenuous.  Not to mention that either an extra SOQL query needs to be added to the transaction to lookup the PS Id, or the PS Id needs to be hard-coded somewhere, which is also a bad practice especially from a backup/restore perspective.  (At a minimum, accepting a PS API name vs Id would be one solution that avoids both issues, yes?)

If the direction of Salesforce is to "user mode everything", then the ability to specify a PS isn't just needed within Apex, rather the same capability will need to be delivered within Flows as well, right?  Would it really make sense for each flow action to specify the PS the action should run under?  The system/user mode and "How to run the flow" is specified at the flow level already, wouldn't it make sense to specify a PS to execute with at the flow level as well?

What I'm getting at is there seems to be a big disconnect between the flow world and the Apex world.  Flows decide security at the "front-door" and it applies to the entire transaction.  Whereas Apex seems to apply security point-by-point, DB operation by DB operation.  It's messy and confusing.

The general guidance we give developers today is to think about Apex code in terms of the "front doors":  If it's something end-user facing like a web service or UI controller, then you need to enforce user security and use user mode.  But if the code really belongs in the "system automation" domain where the code knows what needs to be done regardless of the assigned user permissions, then use system mode.  And you adopt patterns for organizing code and promoting reuse that accounts for the distinction and intentional choices (with lots of "inherited sharing" for code that is truly reusable).

Personally, I like the "front-door" security model implemented by Flow and I really wish it could be modeled within Apex (and elsewhere!) as well.  Imagine if I could mark-up my UI controllers with a "@Security(mode=user, permissionSet=something)" annotation, and the same security applied for the duration of the transaction, just like a flow.  Likewise for annotating a trigger, batch class, scheduled job, web service, etc.  You know, all the "front-door" Apex classes.  (And while we're at it, let me also apply security at the Connected App level so I can better restrict what each Connected App can/can't do.  Granting FLS to a user grants them access across the board via all apps the user has access to, and that's often not a good thing.)

I really wish Salesforce would shoot for a security model that's more consistent across the board.   Break down those product silos, you know?

Anyhow, I do not think the ApexUserModeWithPermset feature as currently implemented moves the platform in the right direction.  It's yet another tool being added to the confusing mix of options.  More churn.

If I'm wrong and this feature really is a necessary step toward achieving the target goal, then revealing the grand master plan (that goes beyond just Apex!) would go a very long way to building trust and support with the developer community.

Thank you for considering this feedback.