It's 2025, can we deprecate ui.notify if ui.notification does the job just as well?

[evnchn]

Back in #4950 (comment), it was discussed that the fire-and-forget ui.notify is kept for (1) backwards compatibility and (2) may be more performant than ui.notification.

But then, consider the following:

1. We have once a year to make breaking changes in a major release, say 4.0
2. With Remove cyclic references within clients and elements #4938 and Use weak references for parent slot to avoid cyclic references #5053 reference counting can free the memory for an element without references, and so if we ui.notification now, isn't that element created, stuff sent in outbox, then immediately free-memory, making it as efficient as ui.notify in the server side? Sure, there may be more Vue mount-demount, but it's fine?

Question for the deprecation in the title is, did I miss any genuine use for ui.notify?

NOTE: ui.notification calls Quasar.Notify just like ui.notify

nicegui/nicegui/elements/notification.js

Line 5 in 07d07c3

this.notification = Quasar.Notify.create(this.convertedOptions);

[falkoschindler]

My opinion from #4950 (comment) still stands:

ui.notify has mainly been kept for backward compatibility. But it also might be a bit more efficient (no element to be created, no further client-server communication) and feels more like the original "fire and forget" Quasar notification (groups by default). So, yes, I do think we should keep both. You either want to "notify" the user, or you want to create a "notification" to interact with.