@iHiD Here it is not off-topic anymore 
If we are talking about “fluency in problem solving”, I’m with you. If we are talking about “fluency in a programming language”, I’m not.
Based on my experience in teaching programmers TDD, who are fluent in their languages, all these different kinds of thinking about code, software architecture and problem solving are not related to the language. Those programmers very well code real-world programs in their language without ever thinking about automated testing or how the problem might be sliced differently.
Using the Dreyfus model of skill acquisition, I’d say, they are competent or proficient in their language but novices in problem solving and TDD. They never had to learn that before, as the problems were sliced to bitesize by others. And automated testing was out of their focus until lately.
And of course it can be the other way around, too. If I would learn F#, I would very much start from 0 in F# and maybe functional programming in general, but I have a high level of proficiency in problem solving and TDD.
Taking Exercisms Fluency application to coding, TDD very well is in level 3 proficiency in programming languages: “using the tools and libraries in the broader ecosystem of the language”. Because TDD here is knowing the tools and libraries to apply TDD in that language, not knowing TDD in general.
I know there is languages with a build-in support for testing, but still one can very well write programs without TDDing them. And be fluent in such language without being fluent in the process or the thinking behind Test Driven Development.