How would you measure an unknown clock with only a reference clock to work from?

The Gray counter thing is a real technique but it only covers one case, and I think that's where you got fumbled into. The clean framing is to say the answer depends on wether the unknown clock is faster or slower than 100 MHz. If it's faster, you do exactly what you described: gate a counter in the reference domain and count edges of the unknown clock, accepting that the count is off by one at each boundary no matter what you do. The boundary question is a trap to see if you know the error is quantized to one count and you just synchronize the gate enable into the other domain and state that. If the unknown clock is slower, counting edges gives you a terrible answer, so you flip it: run a fast counter in the reference domain, use the unknown clock to enable or sample it, and count how many reference cycles fit inside one period of the unknown clock. That's reciprocal counting and it's the answer they were probably fishing for. The Gray counter version, where a counter runs in the unknown domain and you snapshot it twice through a synchronizer and subtract, works too but only when the unknown clock is slow enough that you don't miss increments between samples. Saying 'it depends, here are the two regimes, here's the +/-1 error bound in each' is a much stronger answer than any single circuit.

On the pulse one, I ran into somthing similar at my last job but the input was shorter than one clock cycle, so the shift register trick missed it entirely. We ended up latching the input asynchronously first, then clocking the latch clean, and only then feeding the stretcher. The combinational-thru part is what gets you though, becasue if the output has to follow the input with no delay you can't register the path, and that usually means the timing analysis on that one net becomes a whole conversation. Did they say anything about wether the input pulse coud be shorter than a cycle, or was that fair to assume?

On the pulse one, the assumption I'd state out loud is that the input is synchronous to the clock and exactly one cycle wide, beacuse if it arrives from off-chip the OR-with-shift-register output can glitch high for a fraction of a cycle, and whatever samples that output needs its own synchronizer anyway. The other thing I'd mention is that the purely combinational input-to-output path shows up as its own arc in timing analysis, so if the interviewer keeps pushing on the immediate-output requirement they may be testing wether you know that arc exists and can still close timing around it. Did they say what was acutally connected to the output?

Agreed with the two regimes framing, that matches how I'd answer it now. When I had to measure a slow few-MHz clock against a 100 MHz reference at work, one period of measurement only gave about 1% resolution and the customer wanted better. What saved us was averaging over 64 periods of the unknown clock and dividing the total reference count down. Costs nothing in logic, just a bigger counter and a divide, and the accuracy scales with how long you're willing to wait. Worth stating out loud in an interview that resolution trades against measurement time, becasue that's the question they ussually ask right after the reciprocal counting part.

Update: got it sorted. The two-regimes framing was what I was missing, wheather the unknown clock is faster or slower changes the whole approach, and averaging over many periods fixes the resolution problem for slow clocks. For the stretcher, I took the point about stating assumptions: input is synchronous and one cycle wide, so the OR with a short history works fine.