Well, it really evolved from the pressures of complaints...mostly made by me.
The concept initially came about because the staff (of which I am a part) of Aerial Heights decided to abolish currency altogether because inflation had gone out of control. In the threat of loosing my main reason for making the main plugin I have, floAuction, I opted to allow users to auction using their gold if no currency plugin was available (among other reasons).
When I first wrote it (and when this was still part of floAuction), it removed all currency items and then it put them back in the most compact space possible with no consideration for original stack locations. While effective at storing the total balance, it completely rearranged the entire inventory. It was very annoying. You can see that code on floAuction (historical file) line 103. At this point, I also realized that it, if written as it's own plugin, could be used by other shop plugins, prompting GoldIsMoney.
When GoldIsMoney 1 came out, the massive change was to do the withdrawing first allowing a overwithdraw of just enough to facilitate putting back the change with the deposit function. The withdraw part withdraws smaller currency units first and the deposit part deposits larger units first, thereby giving a good balance between the footprint in the inventory and the reuse of existing stacks. This code was extremely long because I was hardcoding each step for each currency unit as you can see in this historical file line 197.
When people wanted Emeralds (up to this point, it was only gold), I didn't want to continue this really long hardcoding. So when 1.2 came out, it was entirely rewritten for the third time. I realized I was effectively preforming the same actions on each unit, so shortening the code tremendously, the units were put in a list and looped through. Since I was assigning the currency to a list, it easily facilitated offering other currency families as well as custom ones. This is what's currently on the "master" (1.x) trunk line 228.
Up till this point, it was an item based currency with a virtual currency backup for offline users. GoldIsMoney 2.0 is a virtual economy with an item sync for online users. While the effect on the user is exactly identical, the setInventoryBalance function did get a little cleanup because it wasn't trying to save the overflow (not enough space) into third location. This is in the setInventoryBalance function line 80 here. The reason for making the primary memory storage virtual was to allow "fake player" accounts, "bank" accounts are also available in 2.0, but they do not currently have an inventory sync.
But there was a notable improvement over the 1.2 code...In 1.2, after withdrawing, any empty stacks were forgotten and any money deposited would have no bearing on previously emptied inventory locations. In 2.0, before forgetting where those emptied slots were, it deposits to ONLY empty slots (still smallest units first), then deposits any remaining to other available slots. This weighs the balance of space vs. maintaining item positions towards the latter, but the latter is the more preferable and thus this is a better option.
Because of how much time I've spent organizing the inventory, one of the HUGEST irritations to me at this time is plugins which make a "setBalance" or something like that function which withdraws the entire inventory and then deposits back what's needed. While it may be a smaller footprint in their plugin (negligibly smaller at that), it's a major overhead to the server at large, and not just for GoldIsMoney, running through the inventory twice as many times, but it doubles the amount of database calls or file writing for ANY currency. Most irritating to me is that because the item positions are lost after the initial withdraw function is called, depositing back in completely reorganizes the gold in the inventory.
The best way to do it would be to "if (newbalance < oldbalance) withdraw(oldbalance - newbalance) else deposit(newbalance - oldbalance)."