Renumber APIs after merge from main added existing 0004

Rx.NET/Documentation/adr/0005-uwp-legacy-threadpoolscheduler-in-facade.md → Rx.NET/Documentation/adr/0006-uwp-legacy-threadpoolscheduler-in-facade.md

@@ -14,7 +14,7 @@ Proposed
 
 ## Context
 
-As described in [ADR 0004](0004-package-split.md), the [`System.Reactive` NuGet package](https://www.nuget.org/packages/System.Reactive/) is no longer the main Rx.NET package. `System.Reactive.Net` is now the main package, with all UI-framework-specific functionality moved into separate packages. This means applications only get support for a UI framework if they asked for it. This fixes a long-standing problem in which self-contained applications using Rx would get a complete copy of the WPF and Windows Forms frameworks even if they used neither.
+As described in [ADR 0005](0005-package-split.md), the [`System.Reactive` NuGet package](https://www.nuget.org/packages/System.Reactive/) is no longer the main Rx.NET package. `System.Reactive.Net` is now the main package, with all UI-framework-specific functionality moved into separate packages. This means applications only get support for a UI framework if they asked for it. This fixes a long-standing problem in which self-contained applications using Rx would get a complete copy of the WPF and Windows Forms frameworks even if they used neither.
 
 The [`System.Reactive`](https://www.nuget.org/packages/System.Reactive/) package still exists of course, but its purpose is now backwards compatibility. It is marked as obsolete, to encourage people to move on to the new `System.Reactive.Net` component (and, if required, to add reference to whichever UI-framework-specific Rx.NET integration components they require).
 

Rx.NET/Documentation/adr/0006-api-compatibility-verification.md → Rx.NET/Documentation/adr/0007-api-compatibility-verification.md

@@ -15,7 +15,7 @@ Proposed
 
 ## Context
 
-The `System.Reactive` component was previously the main Rx.NET component. Unfortunately, for the reasons described in [ADR-0004](0004-package-split.md), it was necessary to demote this package, to enable the UI-framework-specific components to be removed from the main Rx.NET package. `System.Reactive` now has just one job: to provide backwards compatibility. This means it must offer the same API surface area as the v6.0 release.
+The `System.Reactive` component was previously the main Rx.NET component. Unfortunately, for the reasons described in [ADR-0005](0005-package-split.md), it was necessary to demote this package, to enable the UI-framework-specific components to be removed from the main Rx.NET package. `System.Reactive` now has just one job: to provide backwards compatibility. This means it must offer the same API surface area as the v6.0 release.
 
 Additionally, we require that the new main Rx.NET component, `System.Reactive.Net`, maintains backwards compatibility with previous versions. Of course, the very first version to ship will be a special case: there are no older versions with which to maintain binary compatibility. For this first version, the mechanism guaranteeing that `System.Reactive.Net` provides full Rx.NET functionality is the fact that the v7 `System.Reactive` legacy component is compatible with its v6 predecessor: in order for that component to provide full backwards compatibility, all of the Rx.NET v6 functionality must be present _somewhere_ in Rx.NET v7. But once v7.0.0 ships, we will need a mechanism to ensure that all future versions are compatible.
 

Rx.NET/Source/src/System.Reactive/System.Reactive.csproj

@@ -21,7 +21,7 @@
   <!--
   API compatibility validation.
 
-  See ADR 0006-api-compatibility-verification.md for more information about this configuration.
+  See ADR 0007-api-compatibility-verification.md for more information about this configuration.
   -->
 
   <PropertyGroup>