As far as I know we do not need the contrib items, however if I've incorrectly installed Solr I'd like to know how to fix it.
In my mind, your minimalist install approach is the right way to go. I also take a minimalist approach to forking the example solrconfig.xml. When forking the example schema.xml, my approach is semi-minimalist - the "primitive" fieldType entries are very useful to keep around.
If one of these lib directories does not exist, solr should fail hard. This total/crap/ignored is an anti-feature.
As much as the little bit of profanity amuses me, I agree with Robert. Config elements that reference invalid information or have typos should result in a launch failure. For solrconfig.xml, that would result in that core not loading. The same goes for errors in a <core> tag in solr.xml. For parts of solr.xml outside of the <core> tags, it should result in Solr failing to start. Unrelated note: This is another indirect argument in favor of Solr no longer being a webapp.
Jan Høydahl, I hope that your proposed config example was just a quick brain dump and you don't really want "str" tags in solr.xml. That would probably make it very hard to catch config errors at startup time.
On a larger XML topic, using generic tags (str, int, etc) might make sense in parts of solrconfig.xml where it is used extensively, but I have sometimes wondered whether there would be fewer problems if we used more specific tags and fewer generic. Making it through the transition period might be a nightmare, though.