> All other format codes are illegal for single argument.

I was wrong. PyObject_CallFunction() handles correctly a single non-tuple 
argument. The problem is only with tuple result of Py_BuildValue().

> What do you mean exactly by deprecating the feature? Emit a warning if and
> only if te format string is "O" (or "S" or "N") and Py_BuildValue() returns
> a tuple?

Emit a FutureWarning if the format string contains the single format code and 
Py_BuildValue() returns a tuple. In 3.8 or 3.9 the behavior will be changed.

> I dislike this path
> because developers would try to make the warning quiet in Python 3.7, for
> example use "(O)" format string, which is less obvious and looks like a
> hack to me.

PyObject_CallFunctionObjArgs(func, arg, NULL) seems obvious and perhaps even 
more efficient in all versions.

> More and more applications use Python bleeding edge (the development branch,
> default), and more and more developers quickly test their application on
> the new Python stable release. Maybe we can "simply" fix the behaviour of
> PyObject_CallFunction() with no transition period:

Ask on Python-Dev. I afraid this is too dangerous. We should have at least one 
release with a FutureWarning.

> Most developers don't expect the feature and so write
> code which doesn't work with tuple arguments.

That is why we should add a FutureWarning. If the code doesn't fail by 
accident, but just works incorrectly, this can be unnoticed. FutureWarning 
could help to fix possible bugs in older Python versions.