Is it practical to build a symmetric encryption cipher that needs to change the key for each process?
As is, this statement is a contradiction of the definition of a cipher and it's key. The key is defined to be an input to the cipher, thus the cipher itself can't change it. More importantly, attack models (ciphertext only, known plaintext, chosen plaintext, chosen ciphertext) assume key reuse, thus no key change for different messages. That important assumption matches actual field use, and arguably dates back to Kerckhoffs.
It follows the One Time Pad does not match the definition of a cipher. The OTP is at best an encryption method. If something in the input of a cipher must be changed from message to message (which is common), that's not the key, it's an Initialization Vector. If something not an input of a cipher changes as the message is processed, that's not the cipher's key, that's an internal state of the cipher (which can be the key of an internal cipher).
Thus we need to do one or more of the following to make sense out of the question:
- Replace the word key by internal state initially setup to the cipher's key, that the cipher is now free to change. That's a fair match for what's asked, is practical, but not quite mainstream. For example, it makes sense to change the key of a block cipher after each block, in order to foil some DPA attacks.
- Replace the word key by internal state initially setup as function of the cipher's key (and possibly other input of the cipher, like IV). Now that's practical, and mainstream (as pointed in this answer): the internal state can be a session key, used as key of an internal auxiliary cipher, derived from the overall cipher's key, and changed after some number of plaintext bytes of the overall cipher. However that's less a match for what's asked, for what's change is an internal key, never matching the key of the overall cipher.
- Change cipher to method or device. That makes us free to change the cipher's key, and ignore the battle-tested, real issues that users will reuse the key initially fed to the method or device, no matter what prescription against that is made. To illustrate the danger of that reuse, see e.g. this the gizmo in anther answer. Even though it uses Quantum Key Distribution, it still needs an initial secret key (source) sent by traditional means like a trusted courier. If that secret is reused because the QKD link gets out of sync, the security claim of the gizmo falls apart.
Some time this change depends on the plaintext and is done automatically.
That's no unheard of, and is OK at least in thory. A block cipher in CBC or CFB mode, and some other ciphers, change their internal state according to plaintext and key. However the mixing of plaintext and key must be carefully analyzed, for it can open to some attack.