Ranges-v3 (the c++11 version with the library implementation of concepts) is certainly a nice library that can be used by more people but e.g. compile-times were a real bummer and it still doesn't compile on msvc.
Also quite frankly: Given that it is yet another library that emulates a native language concept with insanely complex TMP machinery, I'd hate to see that library as a dependency of other header-only boost libraries whose compile-times will then remain insanely high years after real concepts have entered the standard. And I'm not sure if anyone will want to spend the time to properly maintain it once Eric moves on.
You appear to be mistaken regarding a few facts. Firstly, there are now several Ranges implementations around, and I believe ALL of them compile, without hacks, on VS2017.9. Secondly the Standard C++ Foundation sponsored Eric to design and write Ranges v3 for the purpose of immediate standardisation. That makes it unique amongst all libraries entering the standard as far as I know. It was commissioned given Eric's unquestioned reputation in that space as the putative STL v2 (since rejected). Thirdly Eric is no longer the primary maintainer of Ranges v3, nor has been for at least a year or more now. He is wholly consumed with getting the thing through the committees which is extremely detailed, all-consuming work. I've sat in LEWG, it's like watching paint dry as Eric answers again and again the same questions raised again and again. Occasionally there is a nugget of gold in there, and it results in a fix avoiding a corner case problem, but for the most part Eric and Casey have thought through every design point and decision. It's just going through the motions to get the thing over to LWG. There are valid criticism of Ranges however. Firstly, even on a fully compliant compiler, they look to be much slower to compile when used in anger, and that's probably unavoidable without more powerful language abstractions. Secondly, optimisers currently are not well tuned for Ranges, and too easily give up which causes poor codegen. Thirdly, there are definitely problems at the intersection between other stuff and Ranges e.g. Eric wants lots more async and coroutines, and while I am not competent to speak on other intersections, in the area of file i/o I am very sure he is wrong on that, and indeed I dropped async file i/o entirely in P1031R1 after he couldn't give me a compelling use case to retain it. I will be starting work soon on the paper standardising support for next gen storage e.g. Samsung KV-SSD, and Ranges does not fit at all well with that either. Ranges may, or may not, have to be adjusted to cope. I have yet to discuss this with Eric, it'll be next year at earliest. So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not. Niall