Not to beat a dead horse, but this whole issue still baffles me. It's hard to believe that its simply a programming issue since I've had a hard time repeating stuff 100 % of the time. One of the programs I started to watch ; paused and then went back to after recording had finished did NOT at first have the RESUME option. But then when I went back to it later it DID have the RESUME option. I guess I don't know enough of the technical background to understand how this is possible; and I find it hard to believe that somehow this happens randomly! I suppose I'll just have to live with my ignorance, since I suspect I'll never get an answer from Dish. But, all in all I'm happy with the H3 and the different workarounds do give me options. PS... I really don't like the new 52 Remote, and when I called Dish they at least offered me one old 40 remote for free. Since the installer left one old 40 remote anyway, that made me a satisfied customer.
TL;DR: Good software is hard to make.
I don't know what language(s) Dish uses on their STBs, which is why it is hard to say. Based on what I've seen, it probably isn't Java, unless they just have really good Java programmers. I say this because I don't recall seeing the usual slowness in areas which would be attributable to garbage collection like I have seen on many other Java-based systems. It also probably isn't Flash or Flex. I've looked at a bunch of open jobs at Dish and Echostar, but they seem to all be back-end stuff, not STB platform developers. Whatever it is, it is probably object oriented, which means heavy code reuse. This also likely means old bugs can come back to reappear when someone uses an old version of a library to do what they need the software to do.
Anyway, depending on what they are using to code, it might make it easier or harder to end up with a bug which results in inconsistent behavior like you describe. The biggest common flaw that gives you inconsistent results from software engineers failing to implement input validation. Essentially, is the input the software is receiving something acceptable or expected? Software engineers make assumptions all the time about how users will interact with their software. Unfortunately, people are very unpredictable, so often they provide unexpected inputs, and the code is not designed to deal with it, and it causes an exception. If there is no validation that the input is within the range of acceptable values, then unpredictable things can happen.
I am not saying this is the problem with Dish's code, but that is just the most common mistake I've seen over the years. My guess is there is come code to handle the RESUME function which relies on the condition of the recording (some kind of metadata) being an acceptable value for RESUME to be an option presented at the time of the button-press on the remote. That condition probably gets set by some other code which obviously isn't always running when it should, or it isn't setting the correct value, or something else. If we could actually talk to the Dish engineers, we could obviously get a clearer answer.
Dish claims to use Agile development methodology, which is supposed to involve direct interaction with the customers, but few places actually implement that part of it. In Agile, we, as consumers of the software product, should be able to submit bugs, which then are investigated, prioritized, and fixed (or not, depending on acceptance criteria). That is the theory anyway.