The real problem here is that current_ and current are almost indistinguishable now that they both use kebab-case. Even when I knew what I was looking for, verifying that I'd fixed it in diffpdf was hard.

There's also a problem with [range.split.outer] p4 referring to current_ in a function that can be used when Base doesn't satisfy forward_range, i.e. when current_ doesn't exist. That seems like an LWG issue, as it's present in P0896R4.

I think it should say "Initializes parent_­ with i.parent_­ and if Base models forward_range, also initializes current_­ with std​::​move(i.current_­)."

The real problem here is that current_ and current are almost indistinguishable now that they both use kebab-case. Even when I knew what I was looking for, verifying that I'd fixed it in diffpdf was hard.

Can we editorially rename one of them to something that looks more different?

I think that would be a good idea. I'll push a second commit to the branch for #3849

There's also a problem with [range.split.outer] p4 referring to current_ in a function that can be used when Base doesn't satisfy forward_range, i.e. when current_ doesn't exist. That seems like an LWG issue, as it's present in P0896R4.

I think it should say "Initializes parent_­ with i.parent_­ and if Base models forward_range, also initializes current_­ with std​::​move(i.current_­)."

This is subtle: split_view instantiates outer-iterator<true> only when forward_range<V> is true, and we don't care if the body of outer-iterator's conversion constructor template is ill-formed when no one should be calling it.