( I don't know much of EVM wallet flow, may be totally wrong here. )

If I understood correctly, eth provider is injected after FCL login. But I think injecting provider before can be better option.

The flow I see on kitty punch, If I click login, it is popping up me a wallet selection dialog. Now if I add updated FCL I have to first login user with non-evm Flow Wallet to have provider in this list. ( I may be wrong on this assumption, but it seems provider is created on current user )

I think it may be better, if provider is in this list ( as we detect in discovery ) let's say BlueWallet ( hypothetical non-erm flow wallet extension ) and another provider maybe something like ( Other Flow Wallets ) which redirects to discovery.

So when I click BlueWallet it can directly authenticate with FCL ( extension pop up ) and I can use it transparently. ( via just initializing FCL )

( I don't know much of EVM wallet flow, may be totally wrong here. )

If I understood correctly, eth provider is injected after FCL login. But I think injecting provider before can be better option.

The flow I see on kitty punch, If I click login, it is popping up me a wallet selection dialog. Now if I add updated FCL I have to first login user with non-evm Flow Wallet to have provider in this list. ( I may be wrong on this assumption, but it seems provider is created on current user )

I think it may be better, if provider is in this list ( as we detect in discovery ) let's say BlueWallet ( hypothetical non-erm flow wallet extension ) and another provider maybe something like ( Other Flow Wallets ) which redirects to discovery.

So when I click BlueWallet it can directly authenticate with FCL ( extension pop up ) and I can use it transparently. ( via just initializing FCL )

Thank you for the feedback @bluesign and I can clarify a bit on the timing of the provider creation.

fcl.currentUser() is a singleton describing the current wallet session that represents either an authenticated or unauthenticated state. (e.g. it is not a requirement that the user has already logged in).

Apologies if it's not clear in the proposal, but the intended use is actually as you describe: the provider is supposed constructed before the user has authenticated with FCL.

So for the KittyPunch/"Blue Wallet" example, it would be as follows:

1. Wallet-specific FCL Ethereum providers are created during the setup (these services would be fetched from FCL Discovery).
   - e.g. const bwProvider = fcl.currentUser().createEthereumProvider({...blueWallet})
2. These wallet-specific providers are now used to configure EVM wallet connectors for whatever library is used by the dApp. For Kitty Punch, ThirdWeb is used, so the for instance adding FCL wallets may look something like:

   // This adapter will instantiate providers using `fcl.currentUser().createEthereumProvider(...)
   import {useFclWallets} from "@onflow/fcl-thirdweb-adapter"
   
   const fclWallets = useFclWallets() // includes all wallets from FCL Discovery (e.g. Flow Wallet, Blocto, NuFi...)
   <ThirdwebProvider
         supportedWallets={[
          ...fclWallets,
          ...anyOtherEvmWallets
         ]}
   >

   (obviously exact syntax may vary, but critically, the dev would include FCL using an adapter/plugin)
3. The user would authenticate with the FCL wallet through the exact same "Connect Wallet" modal. When a user chooses "Blue Wallet" here, they're actually interacting with the FCL Ethereum Provider
   (thirdweb connect -> eth_requestAccounts for FCL Ethereum provider -> fcl.authenticate)

I'll see if I can make some diagrams & add a better description to make this more clear.

thanks @jribbink for this is great explanation. It all makes sense now, I think this is a great idea and very useful for filling the current gap.