Sorry to bikeshed on naming, but... iter strikes me as a little off.

In contrast, these usages of iter all make sense to me:

multi_point.iter() -> impl Iterator<Item = &Point<T>>
multi_line_string.iter() -> impl Iterator<Item = &LineString<T>>
multi_polygon.iter() -> impl Iterator<Item = &Polygon<T>>
vec_of_strings.iter() => -> impl Iterator<Item = &String>

For a collection of Foos, iter() will yield Foo. But I don't think of a LineString as a collection of Coordinates (it happens to look that way on disk, but so do all of our geometries).

What would you think of pub fn coords(&self) or coords_iter()?

fn coords() might match nicely with the existing:

/// Return an iterator yielding one [Line] for each line segment in the [`LineString`].
pub fn lines(&'_ self) -> impl ExactSizeIterator + Iterator<Item = Line<T>> + '_ { }

/// An iterator which yields the coordinates of a [`LineString`] as [Triangle]s
pub fn triangles(&'_ self) -> impl ExactSizeIterator + Iterator<Item = Triangle<T>> + '_ { }

Hmmmm. I initially added iter() because I expected LineString to have it, mostly when writing internal code. But you're absolutely correct in that the choice stems purely from my own expectations, which are at least partly rooted in the fact that we had already added IntoIter so we could loop over Coordinates, and I was annoyed that we could loop but not explicitly iter().

I'm open to adding coords() instead, but should we then consider deprecating points_iter() in favour of points() in an effort to be consistent?

If we do, I'll probably rewrite the introductory docs a bit to note that we offer four iterators, but note that loops will yield Coordinate (which should be thought of as the default?)

Oh geeze, software is so hard.

Honestly, in hindsight, I think it's a little weird that you can do this at all:

for x in &line_string { 
    ...
}

But anyway, that ship sailed long ago, and maybe consistency is more important at this point. Thanks for bringing up the context, your change seems pretty reasonable in light of that.

Would it be crazy to do all of the following?

• Keep the iter() impl as you have it since it complements the existing into_iter(),
  • Alternatively, we could remove the into_iter impl from line_string, but I hesitate to break things, and I don't personally think it's doing much harm as is, just that there are clearer ways to write it.
• add line_string.coords() which does the exact same thing as line_string.iter() but reads more clearly IMO
• add points() / deprecate points_iter()
  • I think it's pretty idiomatic to omit the _iter suffix when returning transformations of the inner data - e.g. hash_map.values() and hash_map.values_mut() not hash_map.values_iter() and hash_map.values_iter_mut() same with string.chars() not string.chars_iter().

I know it's a real laundry list of things... so if you're in spirit on board, but don't have the time to do it, feel free to punt on some of it.

Thanks for cleaning all these up!