> I can perfectly understand this behaviour if transaction 1 modified
> the emp_no field, but I can not see why it is necessary for an update
> of an unrelated field.

Second transaction have no knowledge which fields was changed by
1st transaction so it must wait for stable master record version.

> Is this an implementation limitation in Firebird or a deliberate design choice?
> If it is a design choice, then what is the reason?

I'd said it is implementation details. Not looked what standard say

> Why would an update on the child table ok but an insert disallowed?

Because this update is not changed FK fields while insert does. So
no needs to check FK in this case

> Why would it be OK if the child row was updated before the insert is run?

Because in this case master record is not changed by currently active
transaction and considered stable.

> If it is an implementation limitation, is it
> fixed, planned to be fixed, or should I add it to the tracker?

You may add it to the tracker of course but do not expet quick fix

Regards,
Vlad