OK, I might have a couple more languages than the average mid-career developer, but I don't think I'm that much of an outlier. So here goes.
I have, in the past 10 years, professionally and successfully worked with C++, Scheme, Ruby, a couple generations of JavaScript and Rust. And I've written a whole pile of shell scripts. These were all "first tier" languages in which I was up-to-date at the time. I've also, as a consultant, delivered projects in C# and Java. In these cases, I didn't know all the tricks, but my code met specifications, it had tests, and it was reasonably clear.
Oh, and I also wrote a bunch of Haskell on my own time, and it was stronger than a couple of the languages that I got paid to use.
But no, I'm not professionally up-to-date in all these languages. My C++ is out of date, JavaScript frameworks change every year, etc.
But if you dropped me in a new job with a new language, I could be delivering business value and clean code inside of two weeks, and I'd be reasonably current on whatever framework I was using within a few months. Yes, it would take slightly longer for Elixir or Erlang, and longer still for something like Coq, because there would be new paradigms involved.
But there really does come a time when genuinely unfamiliar ideas in mainstream tools become rare and special. I'm always happy to learn something new like React's virtual DOM or Rust's borrow checker.
And I know plenty of people who are far, far better than I am.
And this is why I'm generally happy to assume that competent developers can learn on the job if they show any interest in doing so. You really don't need more than one person on a team who knows the deeper trivia of a framework.