Wrong Signature for singledispatch'ed functions/methods

An example:

$ cat -n spam.py 
     1  from __future__ import annotations
     2  from functools import singledispatch
     3  
     4  @singledispatch
     5  def foo(x: int) -> int:
     6      return x + 1
     7  
     8  @foo.register
     9  def _(x: str) -> str:
    10      return "Hello, " + x
$ python
Python 3.11.1+ (heads/3.11:ba88628808, Jan 14 2023, 08:40:06) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect, spam
>>> inspect.signature(spam.foo)
<Signature (x: 'int') -> 'int'>

I would expect here something like <Signature (x: int | str) -> int | str> (i.e. union of types for returned value, same for argument) or an exception.

I'm not sure that the first option is on the table: more accurately this situation fits to case of multiple function signatures (like we have in the stdlib e.g. for the min/max). But the current signature() output is misleading.

UPD: In fact, the Signature must be like <Signature (x: int | str, /) -> int | str>, because:

>>> spam.foo(x=1)
Traceback (most recent call last):
  ...
TypeError: foo requires at least 1 positional argument

Or we can make singledispatch'ed function to be with a positional-only argument iff argument names for different overloaded implementations are different.

PS: Inspired by https://discuss.python.org/t/signatures-a-call-to-action/23580

Reproduce el ejemplo usando functools.singledispatch e inspect.signature, incluido el comportamiento de los argumentos posicionales mostrado en el informe. Decide qué semántica de firma se pretende y, después, añade cobertura de regresión que demuestre el resultado acordado; el issue estará terminado cuando las firmas de singledispatch ya no representen engañosamente solo la implementación base.