This proposal suffers from the same problems as we’re seeing for nested public functions: i.e. identifying the correct ordering of state changes across function calls.
With public functions, the problem is that the kernel circuit needs more information, in order to be sure it can ‘squash’ state read and state update requests.
With private functions (as is being discussed in this thread), the kernel circuit also needs more information, in order to be sure it can ‘cancel-out’ (i.e. deleting) pending nullifiers and pending commitments (the act of deleting this information from the kernel’s arrays is analagous to squashing public state update requests). It’s the exact same problem. So we probably need counters in a similar way as @spalladino has propopsed in the other thread.