Duplicate Configurations feature: promote to stable or remove?

[arkivanov]

The Duplicate Configurations feature has been experimental under a feature switch since version 3.2.0-alpha01.

When the feature is disabled (the default mode), Decompose throws IllegalStateException if it detects duplicate (by equals) configurations. This might lead to a crash slipping to production, which is obviously not good. However, it can also help detect and prevent unwanted navigation state. E.g. one may be willing to use pushToFront for a Friend Profile screen rather than having multiple instances of the same screen in the stack. Or you may realise that the user is somehow able to open multiple instances of a Settings screen, which shouldn't be allowed by your design.

When the feature is enabled, Decompose allows duplicate configurations. This mode does not crash at runtime, you can freely push same screens to the stack, but your navigation may end up in a state you didn't expect.

More than one year has passed since the feature was added. It's time to either promote it to stable or remove it. Please cast your vote below.

[PhilipDukhov]

Ideally, I would have more control over it. For example, some screens would be okay to duplicate, while others would not.

I would love to see a report in my tracking system for particular screens without crashing the app.

[arkivanov]

Thanks for feedback! I've noted this for version 4.0, because currently it would double the amount of navigation API (childStack, childPages, etc.).