sys/net/if_bridge.c
78–79	cdefs.h can be removed, we typically clean such things when touching headers blocks.
81–83	Define exterr category before the sys/ include block.
86	The proper place for sys/exterrvar.h would be after that line, due to alphabetical order.
1000
1022
1090	Why is the original error converted to EINVAL there? Also, one of the principles of EXTERROR() is that it should be used right in the place where the situation occur. So I would expect ifp->if_ioctl() to use EXTERROR() eventually, since this is the core of the error, and bridge just re-transmitting it higher.
1333–1334	I would add the requested interface number.
1443–1444	Again, why is the original error obliterated with EINVAL?
1758	Same note, exterror should be set by bridge_rtupdate() (or its subordinate callees).

sys/net/if_bridge.c
1000	i think this is potentially confusing because "command" here refers to the bridge-specific command (e.g., BRDGADD) rather than the ioctl itself (SIOCGDRVSPEC). however, i think "Inappropriate ioctl (expected ...)" would be fine and also shorter.
1090	i don't have a strong opinion here (it already worked this way) but i believe the intention is that if we can't set the MTU on the new member, this is not a valid member for the bridge, therefore we want to expose it as EINVAL because the user provided an incorrect argument. propagating the error from if_ioctl() can be confusing because the relevance of the error might not be apparent, for example: # ifconfig bridge0 add foo0 BRDGADD: Invalid argument (MTU may not be changed on Tuesday) in this case the error is from the underlying device, but this isn't apparent to the user when reading the error output. the current code instead produces `Failed to set MTU on member interface` in all cases so it's more clear what happened. it might be nice if we could provide the ioctl error as well, but i'm not sure exterr supports this.
1758	`bridge_rtupdate()` is usually called by the kernel when forwarding packets, with no user process. is it safe (or efficient) to set the exterr in that case?

sys/net/if_bridge.c
1758	EXTERROR() is safe to call in any context, except the real interrupt handler (as opposed to ithreads). This is the explicit design decision. In case of kernel thread or user thread that did not called exterrctl(2), EXTERROR() is nop. This is not guaranteed but right now it is.