this was the first time i realized structfun didn't work like cellfun that way.  strange design choice, but that does match matlab behavior and it's been that way for ~20yrs.  Looking at how the current function works, you can always call cellfun(@fun, struct2cell(A), struct2cell(B),...) as a workaround.  obviously the structs will have to 'match' according to whatever @fun wants.

Since the current struct2fun doesn't accept anything but name/value pairs after the struct input, in theory an extension could be written that allows multiple struct inputs, and then the first char/string input is assumed to be the start of the name-value pairs. How much input checking to do on the structs (making sure they match) etc would be a decision to make. I guess it could stop at them having the same fieldnames, and any other checks would be dependent on fun.

updating metadata and marking as a marking this as low severity.  structfun is an m-file, so anyone wanting to take a stab at a patch to implement this is welcome to do so even if it wouldn't make it into core octave.