The point is that it won't be integrated in neither kernel or glibc. At least I can't imagine that this will happen. Why should anybody integrate another binary loader/memory layout into the kernel/libc where there is already a fully working one? Just because some people don't want to spend time/money to port their code to linux? I don't think with an argument like that you get this stuff included somewhere :/ (not even mentioning the flaws in the "windows mechanism").
So no, I don't believe that the environment(e.g. kernel/libc) will be adapting to wine in this aspect.
Don't get me wrong I still think it is perfectly valid that wine is doing that sort of hack to get existing windows applications working but you really shouldn't advertise it as a solution to platform independence and encourage developers to go this way.
Wine is doing fine already in regards to randomization (or not), mostly thanks to wine-preloader.
I see no need for action.
Ciao, Marcus