No, using a one-time-pad to encrypt another key stream is futile, as the original key stream must be at least the same size as the message you're trying to encrypt. So the amount of bits used from the current key stream will at least equal the amount of bits transmitted. For a one-time-pad the key stream must be at least the same size as the plaintext message to achieve information theoretical security. XOR is not the only operation that encrypts the message using the key stream, but no other operation will allow a key stream smaller than the message by definition.
The more clever way is to use a stream cipher. A stream cipher generates the key stream from a statically sized key. This key can be any size, but sizes of 128 bits to 256 bits give the required key strength against brute force attacks. A stream cipher doesn't provide perfect security but it does give you practical security - even against quantum computing based analysis, given a large enough key size.
For transport security you also want to protect against leaking information by message size, plaintext oracles and side channel attacks - particularly time based side channels (presuming that the processor itself is in a secure location).
Furthermore you probably want to protect your message integrity and authenticity by using an authentication tag (using a MAC or AEAD scheme). A one-time-pad - by itself - does not provide integrity or message authentication.
shift(pad2, xor(pad, x))
should avoid the issue. This might of course have some other security implication (like eating some aditional entropy for the shift part), but something other than xor should work, right?. – Filip Haglund Mar 08 '17 at 18:22