Hmmm, I agree this is a bug.
Ok, I admit I don't know what is the "right" way to fix this. I also don't think this issue applies to the clustering contrib only.
There are several <lib/> elements in the example configuration and they all use relative paths to load additional components. So after you change the relative folder structure any "example" using these will fail to load, the clustering component just happens to be loaded eagerly so it triggers a failure sooner.
I've had real life use cases when hard-coded relative paths proved very confusing so I'd opt for something like Erik mentioned – making <lib/> components reference JARs relative to some notion of an "installation" folder. Ideally, this should also be inferred automatically if it's not given on command line and if somebody runs Solr from the unpacked default structure. I can prepare a patch that will try to guess and set "solr.install.dir" based on the classloader URI leading to one of the core classes (SolrCore, for example). Once we locate the core JAR we can sniff for ../contrib and ../dist and if these are present set the install dir in the upper folder.
This is, obviously, a hack. If somebody runs from a WAR file or changes the default directory structure things will break. I assume if they do so they'll also be able to change the example's default paths (or override solr.install.dir explicitly).
I'm also not 100% confident how the above will work in the distributed setting – soliciting feedback here.
Anyway, if the above sound all right I will prepare a patch. I don't have any sensible alternatives other than turning off the clustering component by default. I would be against this, however, because like I said – this only hides the problem, not solves it (the default configuration will still be "unmovable" from the default directory structure).