Local.Readdir currently treats its count parameter as an integral entry count (like is common in the Go APIs), however this is actually a byte count (as in POSIX getdents), not an entry count.

The Diod spec says:

At most count bytes will be returned in data.

under the readdir section.
Which lines up with the count parameter for Read and Write operations of both 9P and 9P2000.L.

I think the fact that this works currently, is coincidental.
The Linux 9P C client (used by mount) passes a byte count in the read message, which is always going to be larger than the actual entry count, since even a single entry is multiple bytes.
I.e. The client may only want 1 entry, but will request a count much greater than 1.

The implementation also does not account for scenarios where the count is too small to fit the first entry.
This makes it impossible for a client to know if the directory is empty, or if they have to re-request with a larger count.

I have a patch that likely resolves all this that I will edit into this post when the PR is up.
But it might sit around for a while as I continue to test it, and others + myself review the code.