Naive question, why do we keep cleanups list instead of generating this line after the call to the host ?

In the case of a lower during an import, we would still need to clean up the lowered list. We could re-write this to use an array/stackalloc and fixed in the case of an import.

I suggest that we try to kill as many by using fixed first and then see what scenarios still need another approach.

I think the nested arrays in public static unsafe void ListParam4(List<List<string>> a) is the nasty example.
I'm confused why the buffers are not freed by the receiving end ? Could you please explain (or link the spec).

It seems to me that if we really need cleanup with dynamic number of elements, perhaps all those elements are just buffers. At lest current code looks like it.
And so cleanups collection could be just list of pointers instead of more expensive delegates.

var cleanups = new List<IntPtr>();

var address3 = NativeMemory.AlignedAlloc(10,4);
cleanups.Add((IntPtr)address3);

/// more code here ...

foreach (var cleanup in cleanups)
{
    Marshal.FreeHGlobal(cleanup);
}

And so cleanups collection could be just list of pointers instead of more expensive delegates.

This one is on me, We had two different clean up code paths a few pr's back and I consolidated both of them and used a delegate because we had two different types and it was simple way to handle it. I hadn't really considered the allocations from the closure. I've got #1143 to track cleaning it up.

I'm confused why the buffers are not freed by the receiving end ? Could you please explain (or link the spec).

There are couple scenarios describe in that doc how to handle lowering but this particular code change has two scenarios:

1. first one is when its an import (we are calling the host/another component). We can lower our type and then clean it up after the call to the external component is complete. - i.e realloc.is_none()
2. We are in an export (meaning the host or another component is calling us). In this case, we need to allocate and lower but that lowered value needs to live past our function call and so the ABI will call us with cabi_post to clean it up. i.e realloc.is_some()

This section has some notes too but I find it harder to parse: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#canonical-abi

I suggest that we try to kill as many by using fixed first and then see what scenarios still need another approach.

Agreed, there was a mix different ways this was done originally... slowly trying to consolidate them all as we learn. I've opened #1150 to track that work