There seems to be some instability in the column width calculation

Interesting, not sure what might be causing this. I could not reproduce exact behavior you have. Does the same issue exist when you simply resize an editor in Blender, or do you have to resize Blender itself?
I do get some text jumping around for unknown reasons well (note that this also affects the header, in which I don't do any custom drawing):

The header background color is much darker than other editors. I don't think this is purposeful?

I did not do it on purpose indeed. It seems to be darker, because I'm copying the theme from the file browser. Is the darker header intentional in the file browser?

It was a little hard to see the advantage of the ResourceCollector abstraction (as opposed to adding everything to a temporary struct) at first.

I understand, it's a concept that is not very common (maybe for good reason?). However, I found it very useful in the past to separate concerns. The main idea is that I can give a resource collector to a function and it will return me something that lives at least as long as the resource collector. This helped me when returning references to data that are sometimes statically allocated and sometimes dynamically allocated (as is the data referenced by the span returned by filter_visible_mesh_vertex_rows) (it helped me in other cases before, but those are not relevant here yet). An alternative would be to always return a vector or an array. Then the caller explicitly takes ownership of the data, but it also forces me to create a new vector, even if it is not necessary. To circumvent this, I could also return a Span and a bool that says if the data has to be freed. This works and is efficient, but it is also cumbersome to manage it makes it easier to leak memory accidentally. I just found it significantly more convenient to simply tell the function how long I want the resulting data to live at least using the resource collector. Hope that makes some sense.

The set of functions starting at draw_float_in_cell seem like they could be better named draw_cell_value_as_label, or something like that.

Sounds like a fine change, I just wanted to keep these names fairly specific right now, instead of overgeneralizing thing code. At first, I even had those functions in a separate file, but I figured it wasn't worth it yet, as this stuff has to change soonish anyway (also depending on at which level we want to implement filtering etc.).

One of the larger interesting implementation decision seems to be that this doesn't use RNA at all to draw the evaluated attributes.

The good thing is, the "core drawing code" does not care whether the cells use rna for drawing or not. So it should be relatively straight forward to use it when we need it. However, especially when we want to display some intermediate generated data, we might not be able to access it through rna ever, not sure.

@Brecht Van Lommel (brecht), adding you as a reviewer, because you worked on a spreadsheet implementation before.

Does the same issue exist when you simply resize an editor in Blender, or do you have to resize Blender itself?

Testing this again now, and no, it's only when I resize the window. Some print statements tell me that it's actually the value that BLF_width returns that sometimes changes when the window is resized. That's quite weird...
I'm not even able to reproduce it consistently though, so I'm not sure if it's worth putting too much effort into fixing it right now.

Looks generally fine.

In terms of implementation I would have expected:

• AttributeColumn to be a generic SpreadsheetColumn not specific to attributes.
• Value drawing to use RNA properties so that number formatting and editing is taken care of by the UI code.

But these are the kind of things that can evolve as the implementation gets completed and more types of spreadsheets are added..

Right, most things in spreadsheet_from_geometry.cc are fairly like to change when the design matures. Right now I didn't want to make it too generic.
Maybe we could even just commit this without exposing the new space in the editor menu. Getting all the boilerplate code for a new editor out of the way, would make it much simpler to continue to work on it.

Just as a side note, I was also testing to define what is visible in the spreadsheet from python today (in the temp-spreadsheet-editor-python-prototyping branch). It was relatively straight forward to get that working based on the spreadsheet_draw.hh abstraction. This experiment just shows that we can easily depend on rna properties where possible and also have editable values:

The spreadsheet in the image is defined by this python file: https://developer.blender.org/diffusion/B/browse/temp-spreadsheet-editor-python-prototyping/release/scripts/modules/bpy_spreadsheet.py
Again, this is just an experiment, but it's interesting to see it working.