I sympathize with both sides of the argument here when thinking in terms of composable inter-canister calls and tend to defer to greater minds than my own in making decisions like this (and am glad such minds have open discussions like this!).
I ended up here, though, because I was surprised to notice that the only call that has access to the “logged in” identity (via the msg.caller property that comes through as part of the public shared(msg) func definition) is the very first call that comes from my javascript frontend canister’s actor. I figured that at the very least any of my own functions (private functions in the same canister) that I call from that function would receive the msg argument. I guess I have to modify all my helper functions to pass msg (or msg.caller) as an argument instead of using the handier automatic property.
Maybe the above objections on both sides of the argument could be resolved by allowing a canister to specify who should be sent along as the caller of the downstream function: self, or msg.caller. Basically allow a canister to choose whether it trusts the downstream canister with the user’s principal on a case-by-case basis, defaulting to “no” to keep things the way they are, but allowing an easier method of enabling that behavior without having to litter your entire internal API with original caller parameters.
Or possibly at least default to sending along the original caller between intra-canister calls. I can’t imagine any reason why I would need to know which canister is calling a private function in my own canister. It’s always myself.