Very nice work once again. I like the idea of using temporary addresses for every transaction, it seems to be a powerful way of increasing privacy. If I'm understanding your proposal correctly, the temporary addresses created by transactions are essentially what you store in the account tree, or you could also say that the account tree essentially contains all the unspent outputs from transactions (aka the receipts). What you have proposed is more similar to Bitcoin than the MBC scheme because it revolves around unspent outputs and brings back concepts like change and coin minting without inputs.
At some point in the future Bitcoin developers may figure out a way to compress all the unspent outputs into a compact structure which can be shared among peers much like in your scheme. At the end of the day your scheme might not end up being much more scalable than Bitcoin. But since your scheme, like the MBC scheme, doesn't use tx scripting, that allows you to implement all these clever mathematical tricks to produce a high level of anonymity and privacy while still remaining much more scalable than Bitcoin in its current state and all current anon coins.
Obviously it wont be more scalable than the MBC scheme but the original scheme doesn't provide the remarkably high level of anonymity that your scheme does and anonymity always comes at a cost. I also noticed that your new solution to preventing small value outputs (aka dust) is to enforce a minimum value output. Micro-transactions are much more costly in your scheme compared to the MBC scheme so I can see why you would gravitate towards that solution but it still seems like a rather poor solution to me, especially if the minimum value were to remain static over time.
A better solution might be to simply have miners enforce a minimum transaction fee. I've never really been a fan of the Proof-of-Stake mechanism but one reason I think PoS can be truly useful is for allowing stakeholders to vote on the minimum transaction fee and other important values such as the maximum block size. The problem of pruning dust really is one of the hardest things to solve I think. Sacrificing micro-transactions for more scalability is probably the best solution for your scheme but there are definitely better solutions for the MBC scheme.