You will note, in most of the past posts I pointed out each of these issues. In most I even showed clips of your code, showing where it was faulty.

Anyway, since we're making some progress here...

You can escape the echo commands in-line just like you did with cat, though in this case, your cat solution is probably more readable and just as effective. (Pun: There were several ways to skin this cat! )

IMHO, these two are the most important of the changes, followed by the speedpatch change above. Informing people in the package description of overclocking, and making sure it's not overclocking for call duration are the key items. Even if it's not doing it on your device, it is on mine. And according to the specs for this dbus object, it should do it on all devices. It may be we have different base variants of Nokia's software (I run PR#.#_002 variant, you probably run PR#.#_000 which is "world" variant). Not that Nokia has ever failed to properly document variant changes per region...

The specs for GetStatus indicate 1-5 to be various stages of incoming call UI setup (1 being initial GSM signaling to 5 being user interface is waiting for press). States 6&7 are handshake states to setup a call, 8 is "in call", and 9+ deal with all other call states (call on hold, call waiting, ending call, call forwarding, etc). So if all you're interested in is UI speed to get the incoming call UI displayed to the user, you really only care about <=4. Boosting though states <8 would seem reasonable for responsiveness, since max boost time would then be your ring time, which most carriers limit to 30-40 seconds.

Essentially, yes. Using the non-SR1 enabled profile as the default, and only enabling the SR1 profile for >= K50 should be how it's done. Even K49 isn't guaranteed to be stable with SR1 enabled, since those patches were in post-K49 release tests now being rolled into K50. (K50 is releasing very soon btw.)

The simplest method would be to use kernel-config to save the current setting into a file and reload that as default on removal. It should be default unless the user played with it. Saving the current config guarantees it's what the user had it set to before installing. As discussed before, you would want to pre-detect if the file exists in postinst and only save the profile if it doesn't already exist. That prevents overwriting the users original settings with those in batterypatch in cases where the package is reconfigured (either by the user or by an app/tool/script).