fixup! doc: clarify that features cannot be both experimental and deprecated

Author: aduh95

doc/api/deprecations.md

@@ -10,8 +10,6 @@ Node.js APIs might be deprecated for any of the following reasons:
 * An improved alternative API is available.
 * Breaking changes to the API are expected in a future major release.
 
-Deprecated features are subject to [semantic versioning][] rules.
-
 Node.js uses four kinds of deprecations:
 
 * Documentation-only
@@ -4681,7 +4679,6 @@ deprecated and will throw an error in a future version.
 [legacy URL API]: url.md#legacy-url-api
 [legacy `urlObject`]: url.md#legacy-urlobject
 [permission model]: permissions.md#permission-model
-[semantic versioning]: https://semver.org/
 [static methods of `crypto.Certificate()`]: crypto.md#class-certificate
 [subpath exports]: packages.md#subpath-exports
 [subpath imports]: packages.md#subpath-imports

doc/api/documentation.md

@@ -46,9 +46,7 @@ The stability indexes are as follows:
 >   we can know that this feature is ready to be marked as stable.
 >
 > Experimental features leave the experimental status typically either by
-> graduating to stable, or are removed without a deprecation cycle. In less
-> common cases, if the feature has gotten large adoption in the ecosystem,
-> they can also leave the experimental status by being deprecated.
+> graduating to stable, or are removed without a deprecation cycle.
 
 <!-- separator -->
 

doc/contributing/collaborator-guide.md

@@ -387,6 +387,12 @@ undergo deprecation. The exceptions to this rule are:
 * Changes to errors thrown by dependencies of Node.js, such as V8.
 * One-time exceptions granted by the TSC.
 
+Experimental and undocumented APIs are not considered stable, therefore are
+typically removed without a deprecation cycle. However, if such API has gotten
+some non-trivial adoption in the ecosystem, it (or a subset of it) can undergo
+deprecation – at which point, changes to that API should follow
+[semantic versioning][] rules.
+
 For more information, see [Deprecations](#deprecations).
 
 #### Breaking changes to internal elements
@@ -526,8 +532,8 @@ the three Deprecation levels. Documentation-Only Deprecations can land in a
 minor release. They can not change to a Runtime Deprecation until the next major
 release.
 
-No API can change to End-of-Life without going through a Runtime Deprecation
-cycle. There is no rule that deprecated code must progress to End-of-Life.
+No deprecated APIs can change to End-of-Life without going through a Runtime
+Deprecation cycle. There is no rule that deprecated code must progress to End-of-Life.
 Documentation-Only and Runtime Deprecations can remain in place for an unlimited
 duration.
 
@@ -1059,6 +1065,7 @@ need to be attached anymore, as only important bugfixes will be included.
 [node-core-utils-issues]: https://github.com/nodejs/node-core-utils/issues
 [ppc]: https://github.com/orgs/nodejs/teams/platform-ppc
 [s390]: https://github.com/orgs/nodejs/teams/platform-s390
+[semantic versioning]: https://semver.org/
 [smartos]: https://github.com/orgs/nodejs/teams/platform-smartos
 [unreliable tests]: https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3A%22CI+%2F+flaky+test%22
 [windows]: https://github.com/orgs/nodejs/teams/platform-windows