Description
Describe the issue
We have a bunch of singleton properties in the toolkit, but with inconsistent naming. I'm wondering whether it wouldn't make sense to have them all converge on a single term, to make them more intuitive for developers. Changing the name would obviously be a breaking change, so this seems like a good moment to consider this with 7.0 around the corner.
A few examples:
For reference, here's the singleton instance ArrayPool<T>.Shared from CoreCLR: link.
Expected behavior
Given that in all these cases we're dealing with singleton instances that are also thread-safe, hence having a similar role (with the given differences due to them being in different types), I figure maybe a single name should be used in all cases. To be consistent with CoreCLR too and since all instances do share the thread-safety feature too, I'm thinking probably Shared?
StringPool will definitely need to use Shared to be consistent with ArrayPool<T>.Shared, so the other two would need to be changed in that case. Otherwise, we could just leave the names different in those cases, looking for feedbacks on this 😄
Additional notes
A decision on this should be made before the 7.0 release is published (including #3230), and I was thinking maybe it'd be best to decide on this before #3424 is merged so that the updated name would already be included in the next preview package for the MVVM Toolkit, so that devs would have more time to get used to that?
Note regarding switching to Shared for messenger, that'd be different from Default being used in MvvmLight, but not necessarily an issue since devs moving from there would already have to make some code changes anyway.