Those were actually removed and not deprecated, so updated the note (they were deprecated long time ago, see #974)

I realized this while writing this guide, but we could actually still add a warning for this. That might be useful?

Probably a good idea, if it's simple to implement? Using __getattr__()?

Looking into it, what I wrote here is actually not completely correct. So PyGEOS objects are indeed fully immutable (a C extension type):

In [1]: import pygeos

In [2]: p = pygeos.Geometry("POINT(1 1)")

In [3]: p
Out[3]: <pygeos.Geometry POINT (1 1)>

In [4]: p.name = "test"
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-4-3cf5ac6b0436> in <module>
----> 1 p.name = "test"

AttributeError: 'pygeos.lib.Geometry' object has no attribute 'name'

But when using the shapely-2.0 branch, we actually create python subclasses for each geometry type (and register those to pygeos), and those subclasses are still mutable:

In [1]: import pygeos

In [2]: p = pygeos.Geometry("POINT(1 1)")

In [3]: p
Out[3]: <shapely.geometry.Point POINT (1 1)>

In [4]: p.name = "test"

In [5]: p.name
Out[5]: 'test'

So in the end, it's not an inevitable consequence of the refactor, but we still have the choice whether to allow or disallow this.
I made a PR #1181 to illustrate how we can disallow this in Shapely 2.0, but to discuss of course whether we want this or not.

And also opened a PR to deprecate it for Shapely 1.8: #1183

Probably a good idea, if it's simple to implement? Using __getattr__()?

Another related issue is creating an object array of shapely geometries, described in #1096. Is it worth discussing? It only impacts version 1.8.

Yes, I certainly think that's worth describing (see also my comment #1180 (comment) above). Will add a section about that.

If including this full code snippet might make the section a bit long to read, we could alternatively also link to the github issue's comment from where I copied this: #1096 (comment) (which might also make it easier to comment / ask questions about it on the issue)

This might benefit from an example showing how to do this directly instead of line.array_interface().

I am a bit hesitant to add an explicit example of accessing np.array(line.coords).__array_interface__, because I can't think of many good reasons you would need to do that directly yourself (also because it is somewhat legacy, with now the more general python buffer interface: https://numpy.org/doc/stable/reference/arrays.interface.html), but it would basically be:

In [1]: from shapely.geometry import LineString

In [2]: line = LineString([(0, 0), (1, 1), (2, 2)])

In [4]: coords = np.array(line.coords)

In [5]: coords.__array_interface__
Out[5]: 
{'data': (94533168670016, False),
 'strides': None,
 'descr': [('', '<f8')],
 'typestr': '<f8',
 'shape': (3, 2),
 'version': 3}

And numpy arrays also have a ctypes attribute, although it is a bit different:

In [6]: coords.ctypes
Out[6]: <numpy.core._internal._ctypes at 0x7f7ca9abdd00>

In [7]: coords.ctypes.data
Out[7]: 94533168670016

For this we could point to https://numpy.org/doc/stable/reference/generated/numpy.ndarray.ctypes.html

I could maybe at least point to those urls.

Pointing to those URLs is fine.

Hope you don't mind using sphinx.ext.intersphinx for the numpy links. Outputs were checked locally to make sure they are the same.

Certainly not, thanks!