Henry Schreiner

If we are setting it equal to something, then what about `= "append"`? That would open the possibility in the future of having different modes (like "prepend").

(If this looks reasonable from a design perspective, I'll start implementing it in scikit-build-core. It goes pretty well with the way `if.` and `if.any.` are implemented there, too.)

I already considered `merge`. Let me bring those four options up at our scikit-build developers meeting tomorrow and see if there are any thoughts there. I'm still slightly in favor...

(@thewtex was in our scikit-build meeting mentioned above). I'd say I'm even on `inherit` and `extend`. `extend` sounds a bit better for a list and a bit worse for a...

Sounds good. Inheriting top level is probably something I won't add to scikit-build-core, but I could see it making a bit of sense here. Would it make sense for anything...

I'm not very fond of allowing multiple variations like that. It makes it much harder for users to discover "prepend", and it doesn't clarify how this is merging with the...

Should the inherit for platform options be a followup? I'm thinking we can rework the platform options as overrides (as they are really just a special case of overrides anyway).

I'm working on docs now. I'm not sure it makes sense to add inheritance to the other areas, though; once key feature of inheritance is that you can use it...

Added some basic docs. I think we should stick with it just for overrides, at least for now, and see how it does and if people need or expect more....

> changed the logic around option stringification to make it possible to inherit from a string value specified elsewhere This broke table entries (see https://github.com/pypa/cibuildwheel/issues/1803). Tables now append or prepend...