log_32(x) is only a constant factor of 5 off of log_32(x). If we are going to call log_32(collection_size) "effectively constant", we may as well call any log-complexity operation "effectively constant". If you call the op "logarithmic-complexity", the "effective-constant" property should be just as clear to someone who knows what's up with time complexities and logarithms plus you gain the benefit of being technically accurate. Actually calling log_2 ops "logarithmic" and log_32 ops "effectively constant" crosses the boundary into being actively misleading.
I think the point is more that the implementation is effectively constant time, even if the algorithm isn't. In the Scala implementation, vectors have a maximum size of 2^32. So we know that a lookup won't need to walk more than 6 levels deep, no matter what.
Hash tables are usually considered to have constant time lookup, but of course in practice they have to deal with collisions. I don't think it's unreasonable to say that Scala's vector lookups are "effectively" constant time, because they are.
That's definitely a fair way to describe things (even if it is strictly less precise than just saying "log_32") but if you're going to do that, you should call all of the logarithmic-in-size operations "effectively constant". Having a bounded max of e.g. 30 lookups isn't markedly different from having a bounded max of 6. Basically... my claim is that it's misleading for the Scala docs to draw the distinction where they've drawn it.
Edit: Ah! I messed up the first sentence of my original comment but it seems to be too late to edit it! I meant to say "log_2(x) is only a constant factor of 5 off of log_32(x)".
