After further feedback from the SMEs (see the linked thread in Max's comment):

1. Incorporate (with edits) the following paragraph by Mario
"

Che is not an IDE per se and doesn't support a particular language. Che is a platform to create remote development environments. Those environments are composed, at least, by one container and one IDE (starting from v7.56 the default IDE is VS Code).

"

For example as:

"

Che is a platform to create workspaces, which are remote development environments. Such environments are composed of at least one container and one IDE.

"
into the following page:

https://www.eclipse.org/che/docs/stable/end-user-guide/developer-workspaces/

2. Incorporate (with edits) the following paragraphs by Mario
"
Che includes a default container (the universal developer image) and some pre-packaged IDEs (VS Code, IntelliJ, PyCharm and Eclipse Theia).

The universal developer image has development tools for the following languages: Java, Scala, C/CPP, PHP, NodeJS, Go, .NET, Python and Rust (you can find more details in the README file). When a developer uses another language or, in general, wants an image with a different set of tools, he should use a devfile or change the default image in the global Che configuration (this will affect other developers).

The list of list of languages supported by an IDE may vary. The languages can be supported natively or through the installations of plugins. For a precise list of languages a developer can refer to the IDE documentation. Developers are not limited to use the pre-packaged IDEs but can define custom ones using a Devfile.  

Eclipse Che includes a list of stacks samples using different programming languages. The examples demonstrate the capabilities of a remote development environments and can be used as a reference to bootstrap a new project (each samples includes a Devfile). The list of samples can be customized by an administrator of Che.
"

(Maybe also state in the first paragraph the fact that "Che is language-agnostic.")

into the following page:

https://www.eclipse.org/che/docs/stable/end-user-guide/supported-languages/

3. Incorporate any info from Artem from https://issues.redhat.com/browse/CRW-3308?focusedCommentId=20901327&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20901327

4. While doing the previous step, split the page into an assembly with two included sections:

Section 1: A 'con_...' concept module with all of Mario's text paragraphs.
Section 2: A 'ref_...' reference module with the list of stacks.

5. In the user guide's `nav.adoc`, move the page

https://www.eclipse.org/che/docs/stable/end-user-guide/supported-languages/

to be the second page from the top directly after

https://www.eclipse.org/che/docs/stable/end-user-guide/developer-workspaces/

under

https://www.eclipse.org/che/docs/stable/end-user-guide/adopting-che/

(because the stack list is more important info to learn about Che/DS than the badges and PR reviews that the other two pages describe).

6. Consider renaming the title of https://www.eclipse.org/che/docs/stable/end-user-guide/supported-languages/ page (not the section) into a title that contains both stack samples and language, for example

= Stacks and languages

Here it can be stacks rather than stack samples because the stack samples would have a dedicated reference module titled Stack samples.

So the page could be titled:

Stacks and languages

And the two sections on that page could be titled:

– Containerization of stacks and languages in {prod} (the concept module content by Mario)

– List of stack samples (the existing list turned into a reference module)

7. Incorporate the info from every single comment by the SMEs in that discussion thread.

8. Either add the following TIP into where the UDI is introduced in the text or incorporate this info from the TIP into concept text:

[TIP]
====
To include other tools or runtimes, an administrator can extend, fork, or replace the UDI image with one that includes the tools appropriate for your organization and your users' needs. That replacement image can then be referenced in the `CheCluster` custom resource, so that users can use the custom image in their devfiles. This will ensure that the tools and runtimes they need are persistent and do not need to be installed on each workspace startup.
Users can also develop their own UDI image(s) and refer to them from their devfiles, as long as the image is published to a registry that is accessible from their organization's cluster. However, this approach is less centralized and standardized, and may not scale or perform as well.
==== 

• NOTE: SME contact for ^ is Nick.

9. Double-check and remove this file, which appears to be an outdated leftover: https://gitlab.cee.redhat.com/red-hat-developers-documentation/devspaces-documentation/-/blob/38636d7bb5d68ac073b206969412634f15522379/modules/end-user-guide/examples/snip_devspaces-supported-languages.adoc#L54