I believe that is actually somewhat intentional, as reading data may have side-effects.

Also, the lua method documentation for on_bus_read states Fires immediately before the given address is read by the core... which makes me wonder, if the callback is to be called BEFORE reading the address (as is being done at least in the case of bsnes), how is the read address supposed to be passed to the callback?

Unlike writes, there's not a before and after value—unless you count registers but those are even easier to peek from the callback than memory is. So the value would be populated with the read function's return value as NesHawk does here, or equivalently from a peek (side-effects shouldn't come into this) at addr with the correct width.

Yes I didn't add it in the description, but it might be worth noting that the reason this behavior happens is because when the read memory callback function for each core (BSNES and Genplus-gx) is called, the value 0 is being passed as the value. My point being that as Yoshi says if the value is populated with the read function's return value, I think it should work, since only one read is happening anyway.

Here's what I mean:

As for the docs, I imagine it means before the address is read by the game's code, but not necessarily the core itself. So the way I understand it, whenever the game needs to read from an address, the read memory function is called (ReadMemory for NesHawk), so the game waits for the return value, meaning that until that value is not returned, the address was not read, even though of course it has to be read before by the core to be able to pass it to the game (and to the callback for that matter). I understood it that way the first time I read it, and if that's what it means, then yes it can be confusing, although I am not sure if it would require an update.

I am also giving it a try and seeing if I can do the fix myself. You can of course do a memory.read_u16_be or something of the sort inside your callback to read the value from the address, but I still think it would be nice to have the value returned and ready to be used inside the callback. I think it might also make it easier to understand why val is being passed, as otherwise it can cause confusion why val is being passed to the callback if it's always 0.

Unlike writes, there's not a before and after value

Well yes, but there's still a before and after state when considering side-effects, so I believe the distinction of before and after still matters. When the docs explicitly specify before, I implement before.

In that regard I'd definitely appreciate an update to the docs to clarify for both bizhawk devs and lua devs how exactly those functions should work. As it reads currently, calling the callback function before a value was read, but including the read value does not make sense.

It makes sense from the perspective of the script author: At the time the callback gets execution, the 'current'/'before' state is visible through the APIs, and since the 'future'/'after' state can't easily be reconstructed, the callback is provided those values via the parameters. It just happens that the val parameter is semantically the value of the memory at addr (and not a register), so for reads there is no difference between 'before' and 'after'.

'Before' in the internal API contract means before. If the implementation necessitates that the side-effects of a read must happen before or during a read, then the memory callback part will have to include an extra peek. (Or return default, which is fine but currently undocumented.)