As others have written, there's basically no connection between Rust's six week release cycle & the rate of actual change to Rust. If Rust switched to a 12 week release cycle, all that would change is that it would take twice as long for features to reach users on stable once they were decided to be released. Feature development is neither release driven nor release constrained.
However, the ground truth is that the design of significant new language features basically stopped in 2018. The work now is shepherding through the language extensions the project already committed to in the first few years after 1.0. For example, const generics, which will have a stable MVP in the next release, was first begun in 2017. Generic associated types, which are still not near stable, in 2016.
And my own view, these remaining features are a nearly "feature complete" Rust. Future extensions will be either more niche (a lot of attention in the last few years has been aimed at features to make writing unsafe code less error prone, which wouldn't visibly impact users who write only safe code) or less substantial (such as a syntactic sugar that would improve a lot of users lives, but not deeply change how they write code). And that's actually very good.
However, the ground truth is that the design of significant new language features basically stopped in 2018. The work now is shepherding through the language extensions the project already committed to in the first few years after 1.0. For example, const generics, which will have a stable MVP in the next release, was first begun in 2017. Generic associated types, which are still not near stable, in 2016.
And my own view, these remaining features are a nearly "feature complete" Rust. Future extensions will be either more niche (a lot of attention in the last few years has been aimed at features to make writing unsafe code less error prone, which wouldn't visibly impact users who write only safe code) or less substantial (such as a syntactic sugar that would improve a lot of users lives, but not deeply change how they write code). And that's actually very good.