> empirical evidence indicates that code at the beginning of CommandLine#run is executed prior to spec_helper.rb getting loaded

You're right; sorry about stating that wrong.

> which is the desired behavior, in my opinion because it allows a developer to call srand in spec_helper.rb and have it do what they would expect (i.e. seed randomization across the entire test run).

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`?

> Regardless of strategy, the seed should be locked/frozen/etc as soon as we call srand because changing it after the fact only means that the user has no way to reproduce the randomization within the test run because RSpec will report the new value as the seed instead of what was actually used.

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.

> Also, RSpec documentation already discourages people from setting config.seed and points them to setting it via the command line using --seed as it should only be set for debugging a specific problem anyway.

This is true.  However, we like to keep parity between the command line options and the options available from `RSpec.configure`.  If we go this route, we'll need to remove the `config.seed=` as part of this PR (and deprecate it in 2.99) since having that API still around makes it a confusing lie if users do use it.

Anyhow, one other concern I have with this `lock_seed` approach (if we do go with it--I still want to think about it) is that there's also the `force` method -- which sounds an awful lot like "locking".  It would be good to unify these into one thing instead of 2.

Thoughts from others?  /cc @xaviershay @JonRowe @alindeman @samphippen @soulcutter