That said, you're not even going about the most inefficient route in the right way. Rather than reinventing the wheel, you should at least look at how input compare modules work in MCUs. Just because you deem that there should be a way doesn't mean there is one, and if there is one it doesn't mean that it will meet your requirements for ease and laziness (not necessarily a bad thing, the field of engineering wouldn't exist if it were not for laziness).
A few problems with your idea is that it's highly redundant (shift registers? parallel searches? for time invariant events entering the system sequentially? That's seriously redundant and overcomplicated. Did you even think about the control logic required to pull off a parallel search? If it was actually required it'd be totally unfeasible to do with discrete components). It also doesn't take into account of the control logic that makes all those large prominent circuit components (mostly timers, counters, and comparators). Notice how registers aren't actually included in that list because they aren't actually needed yet you have them in your design while having none of the required components listed? It's a rather large indication of your underestimation of how much components and wiring it's going to take.
But anyays, this control logic is the most intensive to design and wire in the entire design. But being the least prominent and numerous components in the circuit they are the easiest to gloss over and forget about. Then, of course, there is the "decoding" part of the circuit that must produce a fixed period HI or LO digital pulses from a PWM stream where the HI and LO times are of variable.
Real input compares use a timer to measure the pulse width (nixing the shift register and parallel search). And they might have an analog input comparator too. And then there's the issue of control logic to reset your timer on the falling edge and start it on the rising edge. As for the issue of producing a digital bitstream from PWM pulses, you'd need a digital comparator working with a second timer IC that keeps track of when each the PWM pulse period starts and ends. This requires more logic to sync with the rising or falling edges of the input signal and is not the same as the syncing logic circuitry for the timer that records the widt of the pulse. And then you need circuitry so that the period timer can control when ouput of the digital comparator is so that it updates at the proper intervals to produce a fixed frequency digital bitstream.
The work required to wire up to a single digital comparator or a timer is several times more complicated than just wiring up a clock and regulator to a microcontroller. And the control logic can't even be compared to anything really. It's a bunch of bits and pieces lying around everywhere and a much more wiring between them. And if you trip up just once...good luck finding what's wrong and good luck rewiring it if you do. Microcontroller? Just reprogram - simpler to use, simpler to fix, and can do much more. And if the IR is modulated or the bistream is encoded, you can forget about doing anything discretely.
If you're trying to go for the cheapest, easiest and laziest route, a microcontroller is definately the route to take.
It's rather analogous to how flapping wings first appeared to be the easiest and most straightforward way to achieve flight because we lacked of full awareness of what is really required to pull it off. In reaity it takes way more complexity and effort to pull it off than fixed wing flight.