We got to go through all the badness that was the ATM NAPs (AADS, PacBell NAP, MAE-WEST ATM).
I think exactly for the reason Leo mentions they failed. That is, it didn't even require people to figure out all the technical reasons they were bad (many), they were fundamentally doomed due to increasing the difficulty of peering which translated to an economic scaling problem.
i.e. if you make it hard for people to peer then you end up with less peers and shared vlan exchanges based on things like ethernet outcompete you.
Been there done that.
We've already experienced the result of secure ID cards and the PeerMaker tool. It was like pulling teeth to get sessions setup, and most peers plus the exchange operator didn't believe in oversubscription (can you say CBR? I knew you could), so you end up with 2 year old bandwidth allocations cast in stone because it was such a pain to get the peer to set it up in the first place, and to increase bandwidth to you means your peer has to reduce the bandwidth they allocated to somebody else.
I, too, had a SecureID card, whose PIN I promptly forgot. I actually feel sorry for the poor software developers of that system; who knows what "requirements" were imposed on them by management fiat versus researched from the customer (and potential customer) base? Ethernet != shared VLAN, as I'm sure you know, so equating the two is non-sequitur. Ethernet has grown enough features that it can be used effectively in a variety of ways - and knowing which features to avoid is just as important as knowing which features to expose. "Not every knob that can be turned, should be turned." The challenge to a developer of the software infrastructure of a modern IXP is to take what we learned about the ease of use of shared VLAN peering and translate it into the world of pseudo-wire interconnect. Does it have to be as hard as PeerMaker? Clearly not. If someone is going to jump into that space, though, there's a lot of homework to do to research what a provisioning system would need to do to present as little a barrier to peering as possible. Your argument, and Leo's, is fundamentally the complacency argument that I pointed out earlier. You're content with how things are, despite the failure modes, and despite inefficiencies that the IXP operator is forced to have in *their* business model because of your complacency.