round and promise of a cut is not what makes hopping possible.
Hopping is possible when you can expect more reward from the system than your fair share by changing who you are "contracting" with based on expected income probabilities. But anyway let's not discuss this point as there are more basic flaws here.
I think you're missing a key point about how this system would work. There's no contracting, just proof of work done. You receive proof that someone mined for you and you add them to the next coinbase with equal expected value, then you mine until you find a share and send that share over as a proof of the returned work you did. Then you remve them from the coinbase you're mining. If you receive another share from them, you add them again. This forms a chain reaction that continues until one side defects.
The cost of getting this started, even assuming 99% leech ratio is a very minimal investment. If someone doesn't reciprocate, no problem, you just ignore them for the rest of the session. Once you've found enough reciprocating partners, even the minimal losses stop.
Pool hopping is a very specific way to benefit from a pool that uses the proportional payment method. Redefining it in the way you have does not really serve any useful purpose. If you wish to discuss ways miners could realistically cheat on each other in this system, that could be quite productive in getting this system fleshed out better though. I highly doubt there are many ways to do that though.
When you say there is no "promise of a cut" you are playing with semantics again: a share with a coinbase giving a percentage to one address must be a promise of a cut: it means that its miner was using a coinbase that will give this address a cut if a block is found. The miner who owns the address wouldn't start working on a coinbase giving back the same amount of work if it didn't consider that the other miner will continue working with a cut to it in the coinbase so these shares are indeed a "promise of a cut". If you don't agree with the share being a promise of a cut, the alternative is pretty bleak: there's no way for a miner to check that reciprocity is met and so the system is wide open for cheating.
The crucial difference to promises here is that the main method of operation is not promises. It's proof of work done. No proof, no more cooperation. Nothing this algorithm does is based on trusting promises. It's very cheap to to try if another miner is willing to reciprocate, it can be with a miniscule fraction of the share's value (which is, at this moment around 1636 satoshi per difficulty 1 share). If they don't reciprocate, no problem, just forget about them. After a short startup period, the miner will have a list of other reciprocating miners and can stop looking for new ones.
Sorry but this protocol seems full of big holes and I really don't see the advantage: I'm not even sure what the "needlessly strict pool boundaries" are. Would you advocate a system where there is no pool at all and everyone should look for individual partners with a local "reciprocity daemon" finding/maintaining partners and checking that everything is going on nicely? That would be a mess: with p2pool we have ~200 users (and it's arguably high variance), should I contact them all to setup the thing? What about small miners, who would bother contact them (they don't help your variance much, so why bother)?
This is still an unrefined idea that I'm slowly fleshing out. Yes, a "reciprocity daemon" is pretty close to what I'm planning. However, I don't understand your criticism. Are you trying to say that because no-one is using this, no-one will use this? There are lots of different options to use for peer discovery. Are you trying to say that none of them work?
This could be done in a p2p way or in a centralized way. The centralized option could mean that a server, much like a pool server, would function as a switch connecting different miners to each other. The main difference to a pool would be that you wouldn't need to trust the switch, the worst it could do to you is to not relay your data. The other difference to a regular pool would be that you could use several different switch servers at the same time. I'm also thinking it'd make sense for the miners to use this connectivity to exchange new transactions with the nodes they're cooperating with.
The p2p way would resemble the switch server in that every node would do the tasks of a switch but only for a few nodes. a Bitcoin-style broadcast network could work. I've been toying with the idea of having nodes relay shares to others but only when the share contains both it's own address and the address of the one relayed to in the coinbase. There would only be a few connections per node, so useless connections would be replaced until useful ones were found. I expect this would naturally cluster the network so that once you find a reciprocating node, you find tons of them at the same time.
Eliel's goal seems to be a system that automatically negotiates forming ad-hoc pools between peers. This is as opposed to the current system where miners choose to cooperate with an existing pool setup by someone else (eg, p2pool is setup and maintained by forrestv). I agree with you that this is unnecessary considering that there are already multiple options in the decentralized pool category (BitPenny, p2pool, Eligius, EclipseMC, BitArena, etc), but it is still interesting in theory and might very well be the future of pooled mining.
Yes, you're correct. I'm very much thinking about the long term with this system. A generic protocol like this is something that could eventually be implemented with the reference bitcoin.org implementation.