Hi @danfinlay thanks for the feedback,
Yes, there are indeed 2 different motivations
motivation 2) has already been proposed here separately on EIP-1102 (which is not yet final) see EIP-1102: Opt-in provider access and it is the most urgent motivation in my opinion: Apps are currently asking user to sign a message manually which is very ugly user experience. Worse, to alleviate slightly the problem some apps use a static friendly message, making them vulnerable to replay attacks.
adding it as an optional argument to enable or requestAccounts as mentioned in the comment, make it backward compatible so nothing is blocking wallet to support it today.
But note, that this is not only for WalletConnect like login. Metamask would definitely benefit from this too.
As for motivation 1) I don’t think we need to chose between 1775 and this. We can have both. I have given my opinion on the current 1775 draft here and from what I understood, it force separate apps into their own account, which can pose problem for apps that want to be bridged.
Edit: one thing to note is that if motivation 1) is fulfilled, it automatically fulfil motivation 2) as far as account authentication is concerned but I still favor having it in enable first as this is priority and could reduce back and forth fro solution like wallet connect