Small additions to the register-repo docs (#86122)

1. Adds a note that you can restore older snapshots (to recover from a
failed upgrade) even after newer snapshots were taken.

2. Copies the note about incompatible S3 repo implementations to the top
level to avoid misunderstandings.

docs/reference/snapshot-restore/register-repository.asciidoc

@@ -58,7 +58,10 @@ become visible straight away.
 repository you were using before the upgrade. If the repository is accessed by
 multiple clusters, they should all have the same version. Once a repository has
 been modified by a particular version of {es}, it may not work correctly when
-accessed by older versions.
+accessed by older versions. However, you will be able to recover from a failed
+upgrade by restoring a snapshot taken before the upgrade into a cluster running
+the pre-upgrade version, even if you have taken more snapshots during or after
+the upgrade.
 
 [discrete]
 [[manage-snapshot-repos]]
@@ -112,7 +115,7 @@ clusters].
 [[self-managed-repo-types]]
 ==== Self-managed repository types
 
-If you run {es} on your own hardware, you can use the following built-in
+If you manage your own {es} cluster, you can use the following built-in
 snapshot repository types:
 
 * <<repository-azure,Azure>>
@@ -127,9 +130,27 @@ Other repository types are available through official plugins:
 
 * {plugins}/repository-hdfs.html[Hadoop Distributed File System (HDFS)]
 
-You can also use alternative implementations of these repository types, such as
-MinIO, as long as they're compatible. To verify a repository's compatibility,
-see <<snapshots-repository-verification>>.
+You can also use alternative storage implementations with these repository
+types, as long as the alternative implementation is fully compatible. For
+instance, https://minio.io[MinIO] provides an alternative implementation of the
+AWS S3 API and you can use MinIO with the <<repository-s3,`s3` repository
+type>>.
+
+Note that some storage systems claim to be compatible with these repository
+types without emulating their behaviour in full. {es} requires full
+compatibility. In particular the alternative implementation must support the
+same set of API endpoints, return the same errors in case of failures, and
+offer equivalent consistency guarantees and performance even when accessed
+concurrently by multiple nodes. Incompatible error codes, consistency or
+performance may be particularly hard to track down since errors, consistency
+failures, and performance issues are usually rare and hard to reproduce.
+
+You can perform some basic checks of the suitability of your storage system
+using the <<repo-analysis-api>> API. If this API does not complete
+successfully, or indicates poor performance, then your storage system is not
+fully compatible and is therefore unsuitable for use as a snapshot repository.
+You will need to work with the supplier of your storage system to address any
+incompatibilities you encounter.
 
 [discrete]
 [[snapshots-repository-verification]]