This is different. The balance sheet was a way of rolling up known transactions that already exist in the block list. This is an exploration of never putting transactions into the block list at all.
The balance sheet idea is compatible with the current block list system. However as I mentioned, balance sheets enable you to throw the vast majority of the block list away. A minimal block list suitable for supporting balance sheets consists of blocks containing the balance sheet hash and a nonce. The nonce is changed until the total hash of the previous block's hash, the balance sheet hash and the nonce falls below a certain value. The transactions are ephemeral things which are passed around the network and serve to ensure that everyone updates their balance sheets identically. The transactions never need be recorded in the block list at all and, as I mentioned the block list purely becomes a method of assuring the integrity of the balance sheet.
Therefore, balance sheets is actually your idea when pursued to its logical conclusion as I implied in my first post on this thread. Balance sheets do everything you plausibly propose to do in this thread with a lower storage requirement and bandwidth useage. I believe that balance sheets and the above minimalist blocklist exhibit the lowest possible storage requirements for a Bitcoin-like system.
The question you asked at the start of the thread is
... could the block list be/have been implemented in a way that didn't store the full transactions in the list?
The answer is yes and in this post I've outlined exactly how little you need to store in the block list so long as a client can download a current(ish) balance sheet on start up and receive transaction broadcasts. Nearly full details about startup in the balance sheet thread.
ByteCoin