Yeah, this is mainly because this seems like a largish issue to deal with to make good use of it, so it's sort of been a long term plan.
Because you can create collections and add/remove from them without the collections api or overseer right now, you could persist a replicationFactor that is simply wrong and not adjusted for.
My long term plan for this has been:
As the collections api gets better, stop supporting creation of collections by configuration.
Have the Overseer optionally enforce the replicationFactor over time - if too few nodes are up, it creates new ones, if for some reason too many are up, it removes some - using some plugable algorithm.
As part of this, we can also make ZooKeeper the truth for cluster state - so for example, if you delete a collection and then bring back an old node with a core for that collection, the Solr instance can know that it should simply remove that core and not bring the collection back to life.
One step at a time, but I think there is a lot to do to take advantage of the persisted replicationFactor in a way that makes sense - it wouldn't be too cool if we persisted a repilcation factor of 4 and then the core admin api was used to make it actually 6 and the spec never matched with the model again.