The error you see is a syntax error, because ccall needs special casing during parsing/lowering to be able to be passed through the compiler and handled as a foreign call, as well as for inserting the calls to cconvert and unsafe_convert. It cannot see what types the splatted object eventually ends up as and it certainly doesn’t know that it will be a NTuple{9, Integer}. Since it fails at the syntax level, there is no later type based compiler magic you can do to fix this, you need to (at minimum) change how ccall is handled in parsing & lowering.
@ccall is the “escape hatch” that we use right now in lieu of modifying the parser to make ccall more special - not to mention that any change to the parser there needs to be backwards compatible with the existing syntax, as to not introduce a breaking change. The relevant Scheme code in the parser is here and here. There is a mention of ... in there, so it does already seem to be aware of varargs to some extent, but not so far as to allow splatting of arguments (likely in part because we’d still need to know how many arguments we actually want to pass during link time, if I’m not mistaken). This is something the @generated approach avoids via sleight of hand, by not splatting at runtime, but during compilation/parsing, when the @generated function is compiled for the passed in (known & fixed length) arguments.