Please keep this in mind: modeling something after a particular vehicle doesn't mean it is necessarily safe!
I stand by the assertion that option #1 is not as safe. The reason your Envoy can do it is because you have different buttons for otherwise redundant functions. Because you have the (supremely redundant) on/off switch, the designers can assume that if you want to "unset it" (and there is no button for that) you would switch it to "off". But in a case where there isn't separate on/off and set/(unset) buttons, the assumption has to be that the user is toggling between on and off. So if it is on, the next tap must be off and vice versa. You can't really compare the operation in that regard.
I do get what you're saying with the time thing. If the pedal is held for more than X seconds, turn off the cruise (the assumption being the driver has forgotten it is on). It still doesn't resolve the button function so it is more effectively a hybrid of option #2 and what we have now. It still would not allow your "new" speed to be set.
But we can customize it however one wishes. With your suggestion, here are the options I see now:
#1) As described above. Needs a signed waiver along with the request

#2) As described above
#3) A hybrid of #2 and the current method. So you use the accelerator and it stays on. Tapping the button turns it off. But after X seconds, it turns off so tapping the button turns it on (confusing).
#4) A hybrid of #1 and the current method. Basically same as #3 except tapping the button re-sets the speed instead of turning off.
To be honest, after considering it I still think the existing operation is best. Just tap it to unset it and tap again to set at your new speed. The function of the accelerator pedal while cruise is on is to PASS and the assumption is that after passing, your old speed is resumed. If you want to INCREASE the set speed, just use the accelerate feature of the cruise control instead of the pedal.
Now, onto your new request:
Yes, we have access to non-volatile memory on-board. I'm not sure about the tap-tap-hold thing, but I'll think about it. When we were trying to devise an improvised "nudge" feature we were looking at double-taps and that was proving very difficult and not particularly reliable. A simpler thing would be to just have the memorized speed survive a power cycle (by storing it in NVM instead of VM). If you drive 70 90% of the time, then 90% of the time you'd have the correct speed in memory. Also if it is a custom setting for you, we can just hard code it so that upon starting the car, 70 is the stored speed or even make it so "resume" always means 70 for your car. I can't say I'd recommend that, but it may suit your needs. Although I see how a tap-tap-hold (or whatever) suits it even better, I'm just not certain we can achieve that. The problem is distinguishing a tap-tap from an on-off (or off-on). In other words, it is conceivable that a person is in fact wanting to turn it off immediately after turning it on and liability is always a concern... designing so it acts on the side of safety always.
FYI. There are 6 unused "dip" switches on the board allowing the user to control up to 6 "options". Currently none of them do anything but if you did want to try a feature and decided you didn't want it, we can put the option on the dip switches so you can go back to stock if you prefer. Or we could set up 2 or 3 different "modes" and you can try each one and go with the one you like best after actually driving with it.
Most anything is possible so long as it can be done by software only.