No, you cannot do it right now.
If you need to be able to use the account from both a smart contract and a normal address, then you currently need to set the account to be the application account and to allow the smart contract to issue arbitrary transactions using appropriate TEAL code.
Ok, got it, of course that’s the most general approach.
I would like to create a “smart wallet” that offers extended functionalities (e.g., recovery mechanisms) so having an address controlled by a smart contract is the way to go.
I guess the big hurdle to overcome then will be how to interact with Dapps since they won’t be able to simply send transactions to be signed, it will require to create a new wallet communication standard to implement for Dapps creator (or manually integrate with each of them through ABI if they expose it).
For that purpose, you may actually want to use smart signatures/logicsigs (contract accounts) rather than applications. This is one of the cases where smart signatures are useful.
To make a concrete case: imagine a feature that let you designate a second account as backup for a primary account and a timeout after which the second account can be used to recover the primary account. You need to be able to extend the timeout periodically before expiration and if you fail to do so (e.g., you have lost the primary key), you can then use the backup key.
One way to implement this is to create a delegated signature signed by the primary key that rekeys the account to the secondary key if the timeout is expired. The timeout has to be stored in a smart contract where it can be extended and the smart signature has to check it is part of a group transaction involving the smart contract for approval.
This could work but it is complicated by the fact that you need to store the delegated signature, if you lose it you are out of luck. If a smart contract could be part of a multisig then it could be used to rekey the address directly.
Another alternative would be if smart contracts could store transactions in their state and then send them to the blockchain at a later stage. So you could send the delegated signature to the smart contract and have it issue it to the blockchain if the timeout expires.
or it requires to be called in a group of two transactions, where it is the first trransaction and the second transaction is an application call to the associated smart contract. The associated smart contract can then apply any logic to validate the first transaction and store any required timeout. This is the old way to have an escrow account: Linking Algorand Stateful and Stateless Smart Contracts | Algorand Developer Portal (this is now deprecated for 99% of use cases, but for your specific use cases, this is what you need)
the associated smart contract implements whatever logic you want and can approve specific transactions according to this logic. For example, it may require to be call once alone to initiate the timeout period. And when the timeout period ends, then it can be called together with a rekey transaction of the logicsig account.
Just store the logicsig in the note of a first transaction of the account to itself. This way, anyone can easily recover it.