I think only MassTransit among them has any potential for "material" consequences.
MediatR and Automapper were candidates for removal/factoring out in modern applications even before the announcement (mediatr is a bit controversial because it is often misused and makes logic harder to follow but is popular regardless).
For MassTransit, I think enterprises which use it will have to decide if they want to stay for now on v8 and develop it by themselves or pay for v9, or migrate elsewhere. Luckily, there are quite a few choices for messaging from Kafka to NATS to Pulsar and RabbitMQ is used almost everywhere anyway. Or you can do gRPC streams, or SignalR. Pick your requirements and you have many good choices.
MediatrR is useful for CQRS or if you structure your app around event dispatching. I use it some time, but now I will spend a day or two writing a library because I don't need anything fancy.
Automapper is not a concern. With AI you can map a class to another very fast and have better performance.
For MassTransit I don't care. I work with microservices since at least 5 years and we either used RabbitMQ, NATS, Kafka, Azure Service Bus directly or write our own wrapper.
MediatR and Automapper were candidates for removal/factoring out in modern applications even before the announcement (mediatr is a bit controversial because it is often misused and makes logic harder to follow but is popular regardless).
For MassTransit, I think enterprises which use it will have to decide if they want to stay for now on v8 and develop it by themselves or pay for v9, or migrate elsewhere. Luckily, there are quite a few choices for messaging from Kafka to NATS to Pulsar and RabbitMQ is used almost everywhere anyway. Or you can do gRPC streams, or SignalR. Pick your requirements and you have many good choices.