Three things I can think of:

So there isn’t anything per se wrong with making a list of the parameters. In particular, it will loop over the parameters and create a new list, but you won’t be copying tensors a lot but only references to them. That might make it easier to just express what you want with for loops, even if it might not be the solution with maximal computational efficiency. For example, you could use parameters_to_vector inside the list comprehension (or parameters_to_vector(...)).
You can nest list comprehensions. For example you could usetmp = [[something(p) for p in x[i - 1].parameters()] for x in self.phi]

or so. I would recommend to exercise judgement whether or not this is very understandable and also add commentary what’s going on if you do.
A way to get easier to understand things might be using named functions - similar to parameters_to_vector to achieve the things you want to do.
You might need nested cat/stack if you want to build a “matrix of means”.
If you don’t need gradients, you likely want to detach the parameters before computing with them.

As an aside, some care probably is to be taken with parameters. While I think they will usually come up in the same order for different instances of the same network, I’m not entirely sure that it is a hard guarantee (it might fail if people do really funny stuff in instantiation or use dict structures in older Python, probably not much risk with standard PyTorch modules these days). It certainly isn’t an obvious (i.e. explicit) guarantee to me. That said, it’s not clear to me that it matters at all for your use case (i.e. if you’re taking statistics that don’t depend on the order of the parameters, you should be fine anyways) and it could be that I’m overthinking this.
Best regards
Thomas