If you want a real time confirmation, patch the client to check if the sender really have coins (it may already do this). Once it's done, you don't need to really wait for inclusion in 6 blocks, or even in 1 block (but a transaction can currently be ignored by all blocks and forgotten, or depends on another transaction still not included, so 1 block may be a minimum of security)
Right, you should wait for at least one block to have pretty good reassurance. That's a few minutes on average, not enough for point-of-sale, for example.
Wouldn't this be the same as having only one transaction per block?
Yes, with the addition of the capability of merging parallel streams.
How that merge would be made?
Instead of including the hash of a single predecessor block, you would include the hashes of all predecessor blocks. For the proof of work, you would hash the root of a Merkle tree of all the predecessors, just like you do to include multiple transactions in blocks now.
But if that were true then transaction volume would be pegged to the rate of block creation. The only way to increase circulation would be to have bigger transactions... Won't work.
There is no independent rate of block creation or target difficulty anymore. Just one block per transaction, whenever a transaction happens, with whatever proof of work the submitter can generate. So "blocks" will get generated continually. ("Block" isn't a suitable word anymore, because it implies a grouping of transactions, which isn't the case here -- it makes more sense to just say "transaction" .)