Add more prose use cases

docs/versions/_snippets/content-patterns-list.md

@@ -4,7 +4,7 @@
 | [Section/heading-level `applies` tags](/versions/content-patterns.md#sectionheading-level-applies-tags) | Provide signals about a section’s scope so a user can choose to read or skip it as needed. |
 | [Tabs](/versions/content-patterns.md#tabs) | Provide two sets of procedures when one or more steps in a process differs between contexts or versions. |
 | [Callouts](/versions/content-patterns.md#callouts) | Draw attention to happy differences and basic clarifications. |
-| [Prose](/versions/content-patterns.md#prose) | Provide clarifying or secondary information, explain differences with a "why". |
+| [Prose](/versions/content-patterns.md#prose) | - Identify features in a list of features that are exclusive to a specific context, or that were introduced in a specific version<br>- List differing requirements, limits, and other simple, mirrored facts<br>- Provide clarifying or secondary information<br>- Explain differences with a "why" (e.g. comparative overviews) |
 | [Sibling pages](/versions/content-patterns.md#sibling-pages) | When the information is too complex to be addressed with only the other content patterns. See specific examples in the sibling pages section. |
 
 % | [List item suffixes](/versions/content-patterns.md#list-item-suffixes) | Identify features in a **list of features** that are exclusive to a specific context, or that were introduced in a specific version. |

docs/versions/content-patterns.md

@@ -208,12 +208,12 @@ If there’s a terminology change or other minor change (especially where x equa
 
 ## Prose
 
-**Use case**: Clarifying or secondary information, differences with a "why"
-
-**When to use:** 
+**Use case:**
+* When features in a list of features are exclusive to a specific context, or were introduced in a specific version
+* Requirements, limits, other simple, mirrored facts
 * Cases where the information isn’t wildly important, but nice to know, or to add basic terminology change info to overviews
 * Comparative overviews
-* Differences that are small enough or not significant enough to warrant an admonition or tabs or separate sections with frontmatter.
+* Differences that are small enough or not significant enough to warrant an admonition or tabs or separate sections with front matter
 
 In some cases, you might want to add a paragraph specific to one version or another in prose to clarify behavior or terminology. 
 
@@ -223,12 +223,44 @@ In cases where there are significant differences between contexts, close explana
 
 ### Examples
 
-* In {{stack}} 9.1.0 and earlier, **Spaces** were referred to as **Places**. 
 
 ::::{tab-set}
-:group: one-two-three
+:group: five-six-four-one-three
+
+:::{tab-item} Unique features
+:sync: five
+
+* Each space has its own saved objects.
+* Users can only access the spaces that they have been granted access to. This access is based on user roles, and a given role can have different permissions per space.
+* In {{stack}} 9.0.0+, each space has its own navigation.
+
+:::
+
+:::{tab-item} Unique reqs / limits
+:sync: six
+
+* In serverless, use `Admin` or equivalent
+* In {{stack}} 9.0.0+, use `kibana_admin` or equivalent
+
+OR 
+
+The maximum number of spaces that you can have differs by [what do we call this]: 
+
+* In serverless, you can have a maximum of 100 spaces.
+* In {{stack}} 9.0.0+, the maximum is controlled by the `xpack.spaces.maxSpaces` setting. Default is 1000.
+:::
+
+:::{tab-item} Nice-to-know
+:sync: four
+
+In {{stack}} 9.1.0 and earlier, **Spaces** were referred to as **Places**. 
 
-:::{tab-item} One
+OR
+
+If you're managing a {{stack}} v9 deployment, then you can also assign roles and define permissions for a space from the **Permissions** tab of the space settings. 
+:::
+
+:::{tab-item} Comparative overviews
 :sync: one
 
 The way that TLS certificates are managed depends on your deployment type:
@@ -240,12 +272,7 @@ In {{eck}}, you can manage certificates for the HTTP layer. Certificates for the
 In {{ece}}, you can use one or more proxy certificates to secure the HTTP layer. These certificates are managed at the ECE installation level. Transport-level encryption is managed by ECE and certificates can’t be changed.
 :::
 
-:::{tab-item} Two
-:sync: two
-If you're managing a {{stack}} v9 deployment, then you can also assign roles and define permissions for a space from the **Permissions** tab of the space settings. 
-:::
-
-:::{tab-item} Three
+:::{tab-item} Comparative overviews II
 :sync: three
 
 **Managed security in Elastic Cloud**
@@ -264,6 +291,7 @@ You can augment Elastic Cloud security features in the following ways:
 :::
 ::::
 
+
 ## Sibling pages
 
 **Use case:**