Okay, so, I considered the problem for a while, and I have a reasonable theory about what follow_wrapper_chains was for in the first place.

If you have a generic decorator, like functools.cache(), it usually looks like this:

  def my_decorator(fn):
    def generic_version(*args, **kwargs):
      args, kwargs = do_something(args, kwargs)
      return fn(*args, **kwargs)
    return generic_version

  @my_decorator
  def add_five(i):
    return i+5

If you take the signature of add_five, you'd get (*args, **kwargs), because that's the signature of the wrapper function returned by the decorator.  The decorator doesn't change the parameters of the function, but because of how decorators work it can occlude the proper function signature.  In that instance, follow_wrapper_chains does the right thing, and as a result you get a precise function signature.

(Of course, it would do the wrong thing if your hand-written decorator *also* behaved like a partial application, adding in its own hard-coded arguments, so that the resulting function signature changed.)

Still, obviously it's doing the wrong thing when it comes to functools.partial() functions.

My suspicion is that I'm the rare individual who actually uses update_wrapper on a functools.partial object.  So maybe we have the situation here where, yeah, it's a bug, and we can fix it without causing further breakage.

Maybe we can loop in someone who works on a popular runtime function introspection library (FastAPI, Pydantic) to see if they have any take on it.