First of all, I apologize if it was already suggested, implemented, or if my assumptions are wrong. I'm new and rely on unofficial bevy book.

What problem does this solve or what need does it fill?

To change lifetime of an event, manual event handling must be implemented for all the events. Default 2 buffered cycles is not enough at a times, so some long-lived event api would be very useful.

What solution would you like?

I have a few possible solutions actually.

Event.accept()

In Systems that accept event like this, Event.accept() must be called, it just means that event was used, and needs to be cleaned up.

It is a bit manual, but can be useful for, for example, toasts that only pop up in pause menu, regardless on when they were written.

It is user's responsibility to call this method inside of last event handler.

Some generic System like accept_event:: can be chained by user as well, to add a bit of automation.

Singleton Events

There can only ever be one of them, and they can be active or inactive/exist or not exist. When new such event is written, old one will just be overwritten.

Useful for, for example, background music change event. There will always be one music playing at a time. Some System may accept this as handled.

These are similar to Resources, and can in fact be them.

Custom Event lifetime

#[derive(Event)] #[event(lifetime=100)] struct LongLivingEvent;

Meaning event will live for 100 cycles.

OR/AND

app.add_event_lives::<LongLivingEvent>(Duration);

Usage

Can be used with any System, but the ones with run conditions and such will benefit the most.

What alternative(s) have you considered?

All of the above solutions solve different parts of the problem.

Additional context

None