Let me think of a design pattern (or at least something close) that I'd consider on-topic....
"Mix, match, sort and filter" tape files (like handled in N. Wirth's "Algorithms and data structures" probably fits - That's a pattern that only very rarely shows up these days and is at risk of being lost in history, because the problems (trading algrithm efficiency for fewer tape runs and changes) encountered there are simply no longer existing.
Generally, "patterns" (rather: habits) that were applied back then quite frequently (and often, with reason) would definitely rather fall into the category of an anti-pattern (and, thus, in real danger of complete extinction) these days, like (I'm exaggregating a bit in the following)
- Why start a new compile when we can do with yet another binary patch, bodge or backpack?
- (a consequence of the above) Why do we even start a new program when the old one doesn't yet consist entirely of patches?
- Why is self-modifying code a good idea?
- why is interleaved code execution (unaligned instructions) the holy grail of assembly?
Apart from such examples, I can relly not think of "real Design Patterns" (as in the Gang of Four book) that would fit here and not way better in other places.