In looking to solve issue #9028 "no way to override matmul/@ if __array_ufunc__ is set", it seems there is consensus around the idea of making matmul a true gufunc, but matmul can behave differently for different combinations of array and vector: (n,k),(k,m)->(n,m) (n,k),(k) -> (n) (k),(k,m)->(m) Currently there is no way to express that in the ufunc signature. The proposed solution to issue #9029 is to extend the meaning of a signature so "syntax like (n?,k),(k,m?)->(n?,m?) could mean that n and m are optional dimensions; if missing in the input, they're treated as 1, and then dropped from the output" Additionally, there is an open pull request #5015 "Add frozen dimensions to gufunc signatures" to allow signatures like '(3),(3)->(3)'. I would like extending ufunc signature handling to implement both these ideas, in a way that would be backwardly-compatible with the publicly exposed PyUFuncObject. PyUFunc_FromFuncAndDataAndSignature is used to allocate and initialize a PyUFuncObject, are there downstream projects that allocate their own PyUFuncObject not via PyUFunc_FromFuncAndDataAndSignature? If so, we could use one of the "reserved" fields, or extend the meaning of the "identity" field to allow version detection. Any thoughts? Any other thoughts about extending the signature syntax? Thanks, Matti