Give returning v5 users the assertion rename map

docs/migrations/v5-to-v6.mdx

@@ -173,12 +173,15 @@ It 'adds up to `<($a + $b)`>' -ForEach @(@{ a = 1; b = 2 }) { }
 
 Both were deprecated back in v5 and are now fully removed.
 
-**Symptom.**
+**Symptom.** The command is gone, but the message does not say so. Because `Assert-MockCalled` is still listed in the module manifest, PowerShell tries to auto-load `Pester` to find it and reports the load failure instead:
 
 ```
-The term 'Assert-MockCalled' is not recognized as a name of a cmdlet, function, script file, or operable program.
+The 'Assert-MockCalled' command was found in the module 'Pester', but the module could not be
+loaded due to the following error: [Should operator 'Be' is not registered]
 ```
 
+`Assert-VerifiableMock` fails the same way. Searching for the removed command name is what usually brings people here, so it is worth knowing that the error names neither the removal nor the fix.
+
 **Fix.** Use the `Should` mock assertions, see [Mocking](../usage/mocking):
 
 ```powershell

tutorial/2-testing-a-module/2-first-test.mdx

@@ -137,6 +137,22 @@ You may have noticed the generated test used `Should -Be` and we switched to `Sh
 `Should-Be` is a command in its own right, added in Pester v6, and is [the recommended way to assert in v6](../../docs/assertions/should-command). `Should -Be` is the older operator style — `Should` with a `-Be` parameter — and it is what nearly all existing Pester code, blog posts and Stack Overflow answers use, including the file `New-Fixture` generates.
 
 They coexist in v6 and you can mix them freely, even in one file. This tutorial uses the newer `Should-Be` style throughout.
+
+The names are not a mechanical translation of the old parameters, so if you are coming from v5 these are the ones this tutorial uses, plus the few that catch people out:
+
+| v5 operator | v6 command |
+| --- | --- |
+| `Should -Be` | `Should-Be` |
+| `Should -BeOfType` | `Should-HaveType` |
+| `Should -Contain` | `Should-ContainCollection` |
+| `Should -HaveCount` | `Should-BeCollection -Count` |
+| `Should -Match` | `Should-MatchString` |
+| `Should -BeLike` | `Should-BeLikeString` |
+| `Should -BeExactly` | `Should-BeString -CaseSensitive` |
+| `Should -BeGreaterOrEqual` | `Should-BeGreaterThanOrEqual` |
+| `Should -Exist` | no equivalent, use `Test-Path` with `Should-BeTrue` |
+
+Guessing the name usually fails with a plain `CommandNotFoundException` and no suggestion, so the [Should assertions overview](../../docs/assertions/should-command) is worth a look before you start renaming a suite. The old operators are not deprecated, leaving them alone is a valid choice.
 :::
 
 ## Reading a failure

tutorial/4-mocking/3-verifying-calls.mdx

@@ -125,6 +125,10 @@ Read the last line: it shows the filter that was evaluated *and* the arguments i
 
 This behavior is new in Pester v6. Previous versions called the original command when the filter failed. Tests could still pass based on the real data, and you would trust a mock that was never used.
 
+:::note Upgrading a v5 suite
+This is the change most likely to turn an existing green suite red. Every v5 test that relied, knowingly or not, on an unmatched call falling through to the real command now fails instead. That is the point, those tests were passing for a reason nobody chose, but it is worth expecting when you upgrade rather than meeting it one test at a time. [v5 to v6](../../docs/migrations/v5-to-v6) covers the fix.
+:::
+
 ### Giving a mock a fallback
 
 Sometimes you genuinely want "handle this specific case, and everything else generically". Say so explicitly by adding a second mock with no `-ParameterFilter` — an unfiltered mock matches any call, so it becomes the fallback.
@@ -156,6 +160,8 @@ Twenty tests: the original fifteen, plus five that no longer care what is in `pl
 
 There is also `Should-NotInvoke`, the mirror image, for asserting a command was *not* called — "it did not delete anything", "it did not retry". It takes the same `-ModuleName` and `-ParameterFilter` parameters.
 
+If you are coming from v5, `Should-Invoke` is where `Assert-MockCalled` went. It was deprecated in v5 and removed in v6, and the error you get for it does not mention either fact.
+
 <TutorialChecklist items={[
   {id: 'should-invoke', label: 'I asserted the data source is read exactly once with Should-Invoke -Exactly'},
   {id: 'when-to-assert', label: 'I can explain when asserting on calls is right and when it makes tests brittle'},

tutorial/5-working-with-files/2-testdrive.mdx

@@ -72,6 +72,8 @@ Four real files were written and four are already gone. Look in your working fol
 
 The first test asserts the file is absent *before* the call as well as present after. Without that, a leftover file from an earlier run could make the test pass on its own.
 
+`Test-Path` piped into `Should-BeTrue` is the way to assert on a path in v6. The new assertions have no `Should-Exist`, so if you remember `Should -Exist` from v5 this is its replacement rather than a stylistic preference.
+
 ## Scoping
 
 TestDrive is not one directory for the whole run. The rules that matter day to day:
@@ -97,7 +99,7 @@ Compare against the alternatives from the previous page, point by point. Nothing
   {id: 'testdrive-basics', label: 'I know the difference between TestDrive:\\ and $TestDrive, and which to prefer'},
   {id: 'wrote-tests', label: 'I wrote the four Export-PlanetReport tests and they pass'},
   {id: 'no-debris', label: 'I confirmed the test run left no files behind in my working folder'},
-  {id: 'assert-existence', label: 'I know how to assert a file exists, using Test-Path with Should-BeTrue'},
+  {id: 'assert-existence', label: 'I know how to assert a file exists, using Test-Path with Should-BeTrue, and why there is no Should-Exist'},
   {id: 'scoping', label: 'I can explain when TestDrive cleans up, and why modifications to inherited files survive'},
 ]} />