Thanks for your response. The main point of the idea stated above is to increase the number of transactions in a block, without the need of raising the blocksize, to ensure propagation time similar to its current implementation.

Transactions need to be send and propagated anyway, but why do this twice? First the actual transaction is send, second, the transaction is send in the block body. Larger transactions, say 100kb, also require a larger fee, as in the current Bitcoin protocol, I would not consider that a concern. Also, nowadays large-size transactions can be created and send, too. Actually, that supports the question, why send a transaction twice?

To recap:
-transactions can be of any size, but larger transactions require larger fees
-transactions are propagated within 10 seconds to 90% of the network, and stored in the mempool
-all valid transactions received are hashed (SHA256 / /SHA128)
-a block is max 1 MB, containing a header, and a body. The block body contains  hashes of the transactions. The block header also contains the Merkle root of the transactions of which the hash is included in the block.
-a block is mined, 600 seconds on average, send, and propagates in the network.
-the hashes in the body of a valid block are matched against the hashes in the mempool.
-the block is added to the chain, containing both hashes and transactions.

*blocks send in the network are 1MB only. <-- main point: keep the blocksize similar but increase the number of transactions in the block.
*block stored on the blockchain are 8.8 MB <-- perhaps optimization will decrease the block size