Looks good. It would be nice if the entire config path could be given in the warning, rather than just the local field name, but I suspect that that is too hard to do.

Super! Thanks to the docstring modification it's compatible with the task documentation extensions for Sphinx. I could imagine an optional ticket to further act on the deprecation state (like shuffle deprecated fields to the bottom of the config field list in the docs, or otherwise emphasize the deprecation. But as-is, this should work well.

I think the field validation code (in Config base) can give a full path...

for supporting deprecation, but I'm wondering what the workflow will be. Removing a config field breaks any config file that sets or reads that field, whether or not it uses the default value; is the plan to have users remove any assignments that trigger FutureWarning, then clean up any leftover references when the field is removed? Is there a way to instrument Field.__setitem__?

I've modified it to output the full path in the warning.

Krzysztof Findeisen: what do you mean about instrumenting Field._setitem_? Your sketch of the workflow is basically what I was envisioning. I don't know that there's anything else we can do, other than never remove Config Fields, which seems not ideal.

I just looked at the DM-20378 code and you're basically already doing what I meant (i.e., warning on field assignment). From your description here I thought the fields were testing their state for a non-default value.

Here's the update I plan to make to the developer guide (modulo some questions about pipelines docs links): https://developer.lsst.io/v/DM-20378/stack/deprecating-interfaces.html#config-deprecation

There were no objections, so I am adopting this with DM-20378 as the implementation ticket.