Maybe we could add cases for zip_view in std::views::elements variable
template by unwrapping it to reduce producing superfluous nested type just
like what P1739R4 did.

std::vector<int> ints = {1, 2, 3};
std::vector<char> chars = {'A', 'B', 'C'};

before:
the expression "std::views::zip(ints, chars) | std::views::elements<0>" has
the type
"std::ranges::elements_view<std::ranges::zip_view<std::ranges::ref_view<std::vector<int>>,
std::ranges::ref_view<std::vector<char>>>, 0>"

after:
the expression "std::views::zip(ints, chars) | std::views::elements<0>" has
the type "std::ranges::ref_view<std::vector<int>>"

a simple solution:

call signature:
template <ranges::viewable_range R>
  requires /* see below */
constexpr ranges::view auto elements<N>(R&& r)

description:
* views::elements<N> denotes a range adaptor object. Given a subexpression
E, a constant expression N, and T equivalent to
remove_cvref_t<decltype((E))>, the expression views::elements<N>(E) is
expression-equivalent to:
- If T is a specialization of a zip_view,
 equivalent to std::get<N>(std::forward_like<decltype((E))>(e.views_)),
 where views_ is an exposition-only non-static data member of class
template zip_view.
- Otherwise, equivalent to elements_view<views::all_t<decltype((E))>, N>{E}