[Cupid]

Snu,

I see there has now been some discussion of your other idea... I agree that one would be going too far (especially with the lack of usage of this feature), at present.

However, I think this one would be easier; I think it is a clever idea, and more importantly I think it might be what is necessary to make the feature truely useful and hence justify the effort that Mario put into implementing it in the first place.

[Snu]

This has been suggested before, but I'd like to bring up a particular implementation that could be pretty easy on the server.

With the current contingency groups, if any of the auctions in the group is not won, all remaining auctions in the group are cancelled. That's a bit different from what would be useful for me -- I'd prefer that if the _first_ auction in the group is not won, then all auctions in the group would be cancelled. In other words, if (and only if) that first auction is won, I'd want to go ahead with the rest of the bids.

This would work reasonably well when I'm bidding on multiple items for which combined shipping could mean a big discount. I'd then place a bid on one item I'm really hoping to buy. If that bid succeeds, then I can bid on the seller's remaining auctions knowing that the shipping costs will be reduced. That's a pretty conservative way to bid -- Ideally you'd instead change the bid amounts rather than just cancelling if the first item was lost. But this would be less of a burden on the servers.

Here's a scheme which would -- I suspect -- keep the server time to a minimum. When an auction in a particular contingency group finishes, the result would be:
A) If the auction is lost: Cancel all remaining members of that contingency group. (That's the same as with current contingency groups.)
B) If the auction is won: Change the group ID of all remaining members of that contingency group to 0. In other words, remove their grouping, but keep them active.

By changing the group ID, there wouldn't be any further need to remember any hidden "won" versus "loss" states for each contingency group. I don't know how Gixen is implemented, but my guess is that this would leave the server relatively unburdened.