Boy I did say that didn’t I. 
Posting in this dead topic to make a couple clarifications:
Destinations for the HTTP proxy expire periodically during periods of inactivity. I think the default was like 30 minutes, I’ve got mine turned off entirely and can’t remember. It shouldn’t be necessary to restart the router to get a new HTTP proxy destination in most circumstances. In light of this, I think the bigger concern than profiling by HTTP proxy destination is retroactive linking of expired HTTP proxy destinations by correlating them to another identifier or set of identifiers. A malicious social networking site which logged X-I2P-Dest headers of logged-in users could hypothetically do this, for example. One thing I am doing is trying to see how useful a browser fingerprint would be for this purpose.
As I understand it, the header is actually added in at the server side for HTTP tunnels only. That means that the client can’t just ‘not send it’ and the server always has a destination, although contextually separating destinations and making them exist for a very short term seems to be possible to do in a pretty reasonable way. It’s also easy for a server to not add in the header if it doesn’t want to or doesn’t use it, but it still knows the destination. It merely chooses not to forward it to the service.
As for the modified proxy I never got around to SOCKS in the original version(HTTP works fine though) but I’ve got some time off coming up and I’m going to do a rewrite on top of some of the other primitives I’ve developed. I definitely don’t think it will take as long this time. 
