SecurityStrategyComplex - Denying read still shows summary

Hi Dennis! The voice of reason!
I have a custom function criteria operator called NewObjectId, which evaluates to Guid.Empty. I have a lot of instances where I lock down roles to objects that have already been saved using the Criteria Oid != NewObjectId(). An exception gets thrown on the save because the Oid has been generated before the rest of the members are set in the save operation.
Another example, an Invoice. When an employee is set on the invoice, their current commission rates are set on the invoice as well. On the UI level these need to be locked down because the employee shouldn't be able to change their own commission if they don't have the rights to do so from the Role. However, these properties need to be set in code once the employee is selected. SecuredObjectSpaceProvider doesn't allow this. StrictSecurityStrategyBehavior used to work for me before I switched to SecurityStrategyComplex, but it doesn't work, and I was just told in Q359904 that my request to make it work in SecuredObjectSpaceProvider isn't happening.
These are just two of many examples.
On the opposite side of the fence I have this ticket Q490696, where I can't disable objects once a property is set until the application is completely restarted. It wasn't considered a bug, nope… an "improvement for future versions"
And this current ticket regarding the filtering of ListViews.
So, as you can XPObjectSpaceProvider doesn't quite work for me either.
I'm stuck in between XPObjectSpaceProvider and SecuredObjectSpaceProvider. Neither one do what I need them to do and I'm getting increasingly more frustrated after spending the last 4 weeks redoing all of my roles and actions for this new system, which apparently is still considered to be in prototype phase judging by the responses I've received in SC the last few weeks. I need to start making some decisions on if I've just wasted the last 4 weeks or not. I've been around the block enough times to know that a typical response at this point would be "Well, you should go back to SecurityStrategy if it is better for you" which is not a good answer.
I'm trying to hold out until 13.1 to see if any of my issues with SecurityStrategyComplex will be resolved there, member access based on criteria you've said is supposed to be in v13, but that could be 13.2.8 for all I know.
Thanks Dennis, I apologize if some of my venting got in here. I've seen you guys getting a lot of that lately and have tried to stay out of it but this one is killing me.

Its not like my use case seems all that far out there either. It seems like these would be pretty common requirements for most users of the security system.

Hello Nate,
Thank you for your feedback. We will be glad to try to find acceptable solutions for you when the SecuredObjectSpaceProvider is used, because it seems that it best meets your needs.
I see that you already described your concrete requirement and provided example code at SecurityStrategyComplex: How to modify objects/properties in code when the user does not have the permission? and we will answer you there.
As for the other scenarios you listed here, I would appreciate if you create separate tickets for them and supply small test projects so that we can better understand your concrete requirements and see whether it is possible to address them. Quite likely, these requirements can be fulfilled with the new security system. Even if you cannot use the SecuredObjectSpaceProvider in the end, it is possible to protect data on the UI level by disabling certain control features that we described at SecuritySystem: Write permission based on criteria with enum does not work until application is closed and reopened.
In any event, see the Security - Provide an easy way to create additional objects or modify protected properties in code (preferably within the same transaction) feature request we have in our TODO list to make it easier to accomplish such tasks in the future.
We will also consider documenting these specifics in our documentation: Documentation - Denote that it is impossible to modify protected properties in code when SecuredObjectSpaceProvider is used.
About the new security system implementation in general, we discovered that a number of scenarios that make sense is not possible at the moment, but we plan to research these scenarios in the future. For convenience, I created a KB Article where I detailed the current situation: The State of the New Security System.