why is nftables 'iifname' not matching but 'iif' is, GNU Linux 4.9.59.
 

In GNU/Linux 4.9.59, my existing nftables filters which match on iifname do not get matched. If I change the rule to 'iif' it works, but I don't want that because my interface may not exist at the time of rule creation.
For example:
nft add rule ip filter input iifname "myInterface" counter accept

Also the following doesn't work:
nft add rule ip filter input meta iifname "myInterface" counter accept

both successfully create the following rule, which doesn't work:
iifname "myInterface" counter packets 0 bytes 0 accept

Packets received on the interface do not get counted under this rule, but they do enter the input chain (I have as the first line of the input chain "counter packets 0 bytes 0", ie not match criteria).

If I use 'iif', it matches.

What happened? Do I need to load a module by hand?
thanks!

I think that the interface must exist at the time that the rules are compiled into their internal form.

According to documentation, if you use iifname, the interface does not have to exist prior to creation of the rule, but iif does require that the interface exists.
I have tested iifname on another linux box running 4.9.49 and it works fine.
On 4.9.59 it doesn't, BUT I am assuming that something so basic was not removed from support, and that I am just missing some module to load.
I can't figure out what is missing though!

endianness
 

this turned out to be a problem with string endianness, on big endian platforms. I upgraded to nftables v0.7 and this problem went away.
However, now I am unable to have both dport and sport matching on one rule line.
For example, I used to be able to have the following rule in nftables v0.5 :
tcp sport ssh tcp dport ssh counter accept

Now this does NOT match.
I have to separate into two rules
tcp sport ssh counter accept
tcp dport ssh counter accept

Is this a bug or a *feature*?

I'd say it's a feature. Mixing sport and dport on the same line could lead to confusion, when you could just use ports.