I know we're inconsistent today and we already do this in many places, but I'm a little uneasy about this change.

This is implicitly defining "a view" as "a type which models the view concept", and personally I think "a view" (without the code font) is fine for that informal term. Using code font for the concept itself and for types which model it seems less clear than using code font for the concept alone. You need to read the context more carefully to understand what is meant.

We don't say "a copy_constructible" or "a semiregular" when we mean types that model those concepts.

I would be a little less uneasy if we used "a view type", but I still think "a view" is acceptable for that meaning.

Also, this makes the entry for view in the index of library concepts even more silly. I don't think we need things like "the resulting view is empty" to be indexed as a use of the concept.

Also, this makes the entry for view in the index of library concepts even more silly. I don't think we need things like "the resulting view is empty" to be indexed as a use of the concept.

This is a persuasive point. So, for consistency, do we need to change all views in the Overview section to text format "view", that is, take the first step to deal with inconsistent view/"view" keywords?

In my view (sic), it would make sense to use plain font (and no index entry) for the mentions of "view" in the ranges overview sections. Those are largely introductory anyway.

editorial consensus: do what Jens said ^^^.

Do I need to make changes directly in this pull or reopen a pull request?

If you could just repurpose this PR, that'd be fine!

@jwakely, could you please take a look?

I've rebased this and will commit it, thank you!