Don't apologise - they're interesting.
C
My new emulator
Re: My new emulator
Directly on "is introducing half a cycle of latency in all communications problematic?" and my concerns about cumulative latency, some datasheets — including the one I'd followed — show the refresh signal going active on the trailing pulse of T3. Supposing that were true, the ULA would spot that refresh is active on the leading edge of T4, at that point holding the interrupt line to the same value as A6. The Z80 would then see the change in the interrupt line on the trailing edge of T4, one full clock cycle after the refresh cycle started because it's a round-trip cost.
In that case, the Z80 would fail to begin an interrupt at the end of the current instruction because it makes that decision on the leading edge of T4. Which, on the ZX80 and 81, causes horizontal sync to be delayed by 4 cycles and so messes up the entire display timing.
I learnt this the hard way.
In practice I'd already decided to keep those components that watch the clock line separate from those that watch all the other lines as a simple matter of coding efficiency — the clock line is the thing that changes the most so it's helpful to be able to discard all the components that don't listen to the clock in one fell swoop when deciding who to propagate a message to. Which is a bit like the tree structure that I had but specialised to the most common use case.
That naturally gives me an opportunity to propagate messages from clocked components to unclocked components with no latency. So the round trip becomes half a cycle, making the issue moot. In practice refresh also seems to begin very shortly after the rising edge of T3 (as in, the CPU considers it to be something that happens during T3 but, obviously, acts only in response to the clock), meaning that it should start on the rising edge if you're rounding all timing to the nearest half a cycle, making the issue doubly moot — a full cycle of latency from the round trip would still put the interrupt line in the correct state when the Z80 comes to sample it.
In that case, the Z80 would fail to begin an interrupt at the end of the current instruction because it makes that decision on the leading edge of T4. Which, on the ZX80 and 81, causes horizontal sync to be delayed by 4 cycles and so messes up the entire display timing.
I learnt this the hard way.
In practice I'd already decided to keep those components that watch the clock line separate from those that watch all the other lines as a simple matter of coding efficiency — the clock line is the thing that changes the most so it's helpful to be able to discard all the components that don't listen to the clock in one fell swoop when deciding who to propagate a message to. Which is a bit like the tree structure that I had but specialised to the most common use case.
That naturally gives me an opportunity to propagate messages from clocked components to unclocked components with no latency. So the round trip becomes half a cycle, making the issue moot. In practice refresh also seems to begin very shortly after the rising edge of T3 (as in, the CPU considers it to be something that happens during T3 but, obviously, acts only in response to the clock), meaning that it should start on the rising edge if you're rounding all timing to the nearest half a cycle, making the issue doubly moot — a full cycle of latency from the round trip would still put the interrupt line in the correct state when the Z80 comes to sample it.
Re: My new emulator
Just a quick update on this: as I now have Internet access in my home, I've moved the project to public hosting at https://github.com/TomHarte/Clock-Signal. It's still nowhere near ready for public consumption but a normal end-user website will be forthcoming.
Re: My new emulator
I have to say I'm impressed - runs most things without problems. And being a Mac user I was pleasantly surprised to see a OS X-based emulator. 
One thing that doesn't work quite right currently is hires stuff - the video timing seems to be off and the screen 'loops'.
One thing that doesn't work quite right currently is hires stuff - the video timing seems to be off and the screen 'loops'.