Update selection-matching-options.md

Author: aphillips

exploration/selection-matching-options.md

@@ -185,6 +185,12 @@ As an aside, how does the above express the `when` clause for the value `2.00`?
 
 #### How does this compare to programming language constructs (such as switch)?
 
+It's difficult to say if the MF2 `match` statement should work like familiar selection methods in programming languages. Internationalization APIs, such as resource managers, MF1, and date/number skeletons have tended towards "do what I want", hiding the need for both developers and translators to know about cultural and lingusitic variation and account for it in code. Modern I18N APIs hide most of this complexity. Some of the analogous cases in I18N APIs are:
+* resource fallback with sparse population
+* skeletons for dates, such as (`yyyyMMddjm`) do not require translators to touch "picture strings" (such as `MM/dd/yyyy HH:mm a`) to handle the time or date separators `/` and `:`, the use of 24-hour time vs. 12-hour time, the order of the fields
+
+When coding a plural using ICU4J's `PluralFormat`, the developer only needs to worry about _specific value_ messages (`when 1 {This is your last chance.}`) vs. value based messages (`when one {You have {$count} chance remaining.}`).
+
 Many programming languages feature multi-value selection using logic constructs such as Java's `switch` statement. These statements do depend on the order of the "cases":
 
 ```java
@@ -198,17 +204,37 @@ switch (count) {
 
 Programming constructs like `switch` generally match a single value exactly. Sometimes developers use features, such as "fall through", to allow two or more blocks of code to operate on a single value. But the core of a `switch` is binary matching of the value. Generally the same input (`count` in the example above) can't match more than one `case`.
 
-// more work needed
+We could model `match` as a switch:
+
+```
+match ($count)
+when 1   {This is your last chance}
+when one {You have {$count} chance remaining}
+when *   {...}
+```
+vs.
+```
+match ($count)
+when one {You have {$count} chance remaining}
+when 1   {This message cannot be reached in English, but would be reached in Japanese!!}
+when *   {...}
+```
+
+This exposes developers and translators to managing the complexity versus having the API take care of it.
+
 
 #### Are there other complex matching cases? Or is `plural` everything?
 
-Currently there are no other complex rule-based selectors. However, there are a number of cases where complex matching can come into play. Some potential examples:
+Currently there are no other complex rule-based selectors in ICU. However, there are a number of cases where complex matching might come into play. Some potential examples:
 
-1. **Date/time based selection.** Particularly for more modern time APIs, such as "Temporal" types, the ability to match when fields are or are not present, when values vary by culture (particularly relative time values such as `yesterday`, `tomorrow`, etc., where some locales have words for "day before yesterday" etc.). Another example are variations in phrasing. For the time `8:30` an American would say "_eight thirty_", while British or Irish speakers might say "_half nine_"
+1. **Date/time based selection.** Date/time types, including the newer Temporal types, can present complex matching needs. While _incremental time_ values (such as `java.time.Instant`, `java.util.Date`, or JavaScript's `Date`) can resolve every field and be cast to any time zone, Other types, such as `java.time.ZonedDate`, are incomplete. There are different calendars that can affect presentation and selection as well. Some cases for complex time selection include:
+   * **Relative time formats.** The values available (such as `yesterday`, `tomorrow`, `day after tomorrow`) vary by locale. 
+   * **Phrasing variations.** For the time `8:30` an American would say "_eight thirty_", while a Brit might say "_half nine_".
+   * **Periodic time formats.** Recurring values might require message selection.
 
 1. **Measurement selection.** Selectors based on unit of measurement sometimes vary--even based on application-specific requirements. For example, turn-by-turn directions in mapping applications will choose between `km` and `m` (or `miles` and `feet`) based on some arbitrary distance, e.g. `0.5 miles` (2640 feet) vs. `1500 feet`
 
-1. **Gender or part-of-speech matching.** Grammatical gender is strongly linked to language and varies by language--very much like plurals. These types of selection might not have the multiple selection quirks of plurals, but will have varying shape by locale.
+1. **Gender or part-of-speech selection.** Grammatical gender is strongly linked to language and varies by language--very much like plurals. These types of selection might not have the multiple selection quirks of plurals, but will have varying shape by locale.
 
 1. **Application specific selection.** Developers may need to write selectors with varying degrees of selection. For example, one might have a message that varies by category and then, for specific items, by sub-category: