I never really liked asynchronous logic. The input pulse is apparently unrelated to the clock and it could turn out that the input bit sets the flop a couple of nanoseconds before the falling edge of the clock resets it. Runt pulses seem guaranteed.
In my first description, I chosen this solution since the OT didn't define setup times, delays, and other important info if you want to make a clean RTL design. Remembering that this question was placed in the FPGA/Microcontroller forum, I think the OT was looking for logic code to put in a FPGA or PLD.
If I were to do a cleaner version of something along the line of interpreting the OT's inputs, I would use 2 D-flipflops in a row, DQ-DQ, with positive and negative edge triggered clock input shifting the input at every clock transition. This would be clean and no async.
Data in would come from the OP's data in.
Out would be DFF's #1, #2 output OR ed together.
No async here, the input is just being shifted every rise and fall of the clock, unless you have a really old PLD/FPGA from years back which couldn't do positive and negative clocking on a macrocell.
BUT, looking at the OT's second diagram, his output swings immediately after the source rises, exactly 50% in-between a clock cycle.
I guess you can cut my design down to 1 D-FF and OR the input with the output of DFF's for the effect.
Without knowing why and how the OP needs this pattern, what it is being used for, this is the best suggestion I can make.
However, the best FPGA solution is to do all logic on a single rising edge, synchronous clock design if possible. All all IOs, especially if high speed, are synchronous DFF driven or data inputted unless you are struggling to preserve macrocells.
The last solution is just to use a enable low transparent latch (tied to clk). When the !LE input his high, the output = the input (in) in real time, but, when the !LE goes low, the output holds the last state. This might be finicky due to the timing of the OP's source waveforms.