Options are:
Parser function syntax feels more natural here. This choice has a bearing on T373253: Develop semantic / distinct representation for wikifunctions output in Parsoid DOM
I think the initial proposal from wikifuntions was {{#function|...}} but I don't know what the arguments are. We also need to discuss the internal type used for the arguments, and whether this is going to be a self-describing zobject type.
Syntax was planned as something like {{#function:Z801|Hello}} or {{#function:Z12345|5|mi|km}} or {{#function:Z12345|Q12345|{{{CURRENTDATE}}}}} or even {{#function:Z12345|Q12345|{{#function:Z801|Hello}}}}, with (generally implicit) named parameters of parselang and renderlang, so {{#function:Z801|Hello|parselang=en|renderlang=en}} etc..
Wouldn't arguments be opaque to Parsoid?
So no named arguments for wikifunctions, just positional arguments? If there are (future?) named arguments, how are (localized) parselang/renderlang disambiguated?
It would be better to get the output language implicitly from the parser context, aka Parser::getTargetLanguage(), and there's a proposal in T114640#9059438 to make the Parser's target language follow a wrapper div/span.
There's another proposal in T374616 to allow plumbing structured data through arguments in nested calls without forcing everything to pass through strings.
I think we should also be able to to specify arguments by name, so {{#function:Z19708|that=2/1|this=5/1}} would return 5/2.