The Polkadot multisig is designed to be "stateless", which means it has many different behaviors when compared to standard multisigs like Gnosis on Ethereum.
The Polkadot multisig is ultimately designed to minimize the amount of on-chain state needed, since this is one of the major long term costs and scaling factors for blockchains.
When you are doing the multisig approval process, by default, Polkadot JS only records the hash of the call data on chain, and waits for all approvals before requiring the final call data to be posted to the chain.
With this design in mind, let's answer your questions:
Is there a way to handle multisig initiation to final approval with only on-chain data?
No.
How can the call data be stored on-chain?
You can place arbitrary data on Polkadot using the Preimage Pallet, but this will not directly help the multisig execute. You will still require logic for the user to look up this call, and provide it back to the multisig pallet through the final approval transaction.
Why doesn't polkadotjs store the call data on-chain?
Polkadot JS is also stateless, and the multisig pallet is designed explicitly to keep the call data off-chain.
This is why other end to end multisig solutions like Multix exist.
I also want to note that if you are building your own system, you do not need to strictly use Polkadot's multisig. You can develop your own multisig pallet, there are examples of that, or use traditional smart contract platforms on Polkadot to provide 1:1 support to the multisigs you are used to in Ethereum.
The main thing I want you to take away from this is that all design decisions have tradeoffs.
I am sure you are looking at this response and thinking "wow the polkadot multisig system really sucks, I can't do what I want with it", and from your perspective you are probably 100% correct.
But as I mentioned, by keeping the multisig stateless and keeping data off-chain, we reduce a lot of long term debt to the chain, and make a more scalable and resilient platform.
With the combination of off chain layers, we can ultimately provide exactly the same experience to end users (as Multix and others have done), but as an application developer trying to build on top of the Polkadot bare metal, your abilities will be more limited as a result.
