Classic VLIW architectures provide this feature. Operations are statically scheduled with fixed latency and the old value would be associated with a register name until an overwriting operation completed. Texas Instruments' TMS320C66x DSPs are modern examples.
The MIPS R2000 had a limited form of this in its delayed load slot. Since loads had a latency of two cycles, an instruction immediately following a load could read the old value from the loads destination register if the load was a cache hit (a cache miss would return the newly loaded value).
(Delayed branches are similar except that instead of the old value of the program counter being preserved, the expected value if there was not a branch is provided. ARM, which mapped the program counter to a general purpose register, also had an interesting feature of exposing the pipeline delay (of the original implementation) between instruction fetch and register read for execution such that a read of the program counter would not give the address of the executing instruction.)
If an architecture does not define a non-zero latency of operations, hardware cannot determine when a new value would become visible. With architectural zero-latency operations, an instruction's result may be sourced by an immediately following instruction, requiring hardware checks for availability in a superscalar design (or a scalar design with greater than one cycle execution latency) but making limited instruction fusion more practical. With non-zero latency operations, software must ensure that data dependencies are expressed, that a dependent operation is executed in a later cycle.
Static scheduling introduces significant constraints with respect to binary compatibility if hardware is to remain simple; the latency of an operation cannot change. With explicit parallelism but one cycle latencies, all operations within a cycle-chunk can execute in parallel without dependency checks and a straightforward operand availability check can stall the next chunk of internally independent operations; this represents a compromise between the extremely simple hardware of classic VLIW and the more complex hardware of in-order superscalar designs.
(The handling of write-after-write hazards for an in-order design with out-of-order completion seems loosely related. A later but lower latency instruction must be prevented from hiding the result of an earlier but higher latency instruction to the same destination. One way of doing this is by having register writeback in the same cycle for all instructions and using register name versioning in the result forwarding network.)