> I'm confused: I thought the point of this feature is to have us seed randomization for the user -- so if they wanted to use this feature, why would they call srand in their spec_helper.rb?

Excellent question. They shouldn't! But... If they do, it would be mighty confusing if `srand` does nothing, which is exactly what happened to me when I ran across this and put `srand 123` in my `spec_helper.rb`.

> Well, it would work fine as long as the user only uses randomization within code executed by their examples, rather than in code run while loading their specs. Maybe that isn't a safe assumption, though.

I'm not sure I follow. Previously, the seed was only used for randomly ordering specs, so it only mattered that it was set prior to ordering. And at the time the specs were ordered, I'm assuming there were no hooks left that could change the seed. The seed is now significant at a much earlier point in the call chain. If we allow it to be changed, then it means we can't accurately report what was used.

The last points make sense to me (removing `config.seed=` and uniting forcing, which is essentially ignored for the seed right now).

I think these are the two use cases we're looking to choose from:

1. `srand` is called as early as possible (prior to any developer code being loaded), thereby allowing developers to call `srand` in their own code, specs, and even configure blocks and/or hooks and see expected behavior (that their call to `srand` sets the seed and `srand` is not called again unless they call it again themselves).

2. `srand` is called as late as possible, thereby allowing the ability to set the seed in a configure block. This remains consistent with the current configuration interface.