Does the key schedule function need to be a one-way function? For some key schedule $e_n(e_{n-1}(k))$ (where $e_{n-1}(k)$ is the result of the previous round) , does $e$ need to be a one-way function?

In the case of DES or Rijndael the key schedule doesn't really look like one, as the adversary only has to reverse the operations to get the input.

My question is this:

In the case of the well-studied Rijndael,


What are the implications of replacing the iterated schedule $e_n()$ with a one-way function $f$?


My guess is it would increase linearity, leading to a weak cipher. So,


What if we added a one-way component to $e$ such that 


$$e(x) \leftarrow s( r (f (x))) $$

where $s()$ and $r()$ are the s-box and bit-shift functions respectively.

Note: I ask about Rijndael where I really mean any block cipher that is secure, eg. Rijndael but I'm not exactly sure how to phrase that.
As fgrieu already pointed out, using a OWF in the way you describe would make the key schedule not efficiently invertible (or even not invertible at all), meaning you would need more memory/chip space to store the user-input key in order to efficiently encrypt more than one block.

In terms of other implications, if the key-state update function $e_n(\cdot)$ is non-surjective then the later round keys will have less entropy than the user-input key, and hence may be guessed with less effort than with the current AES key schedule.  This could make the last rounds easier to peel off.

However, if $e_n(\cdot)$ is such that every output bit is a high degree non-linear function of every input bit, then any such loss of entropy would likely be very difficult to exploit, and also would likely make related key and biclique attacks more difficult.

You should also be aware that OWFs can be used in the key schedule in a different way than you describe -- i.e. as round key extractors instead of as key-state update functions.  So you might have a permutation (perhaps even a linear one) to update the key-state between each round, but then derive each round key from the key-state using a OWF.  As a concrete (but slow) example, your key-state update function might be to add 1 (or some other constant) to the user-input key between each round, and then extract the current round key from that by hashing the key-state with a cryptographically secure hash function like SHA-256.  As a much faster example, Serpent uses a linear key-state update function, and non-linear round-key extractors (though in that case they are non-linear permutations using the Serpent s-boxes instead of OWFs).