diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5bd52aa..3959551 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,13 @@ covering only what changed for that package:
 [PostgreSQL](src/EFCore.ComplexIndexes.PostgreSQL/CHANGELOG.md),
 [SQL Server](src/EFCore.ComplexIndexes.SqlServer/CHANGELOG.md).
 
+## 5.4.1
+
+One fix, to the index-name check: it compared names per table on every provider, so on SQLite a name
+reused on another table scaffolded cleanly and failed when the migration was applied.
+
+- **Fixed:** on SQLite, a complex index name is checked across the whole database at `migrations add`, not per table. SQLite rejects a second `CREATE INDEX` under a name already used on any other table, and ignores the schemas a model configures, so two tables sharing an index name — two complex indexes, or a complex index and a native `HasIndex` — scaffolded cleanly and failed when applied ("index … already exists"). The scope is now the provider's: per database in the core, which also serves providers without a satellite; per schema on PostgreSQL; per table on SQL Server, where reusing a name across tables stays allowed. **Upgrading:** a SQLite model that reuses a complex index name across tables now fails at `migrations add`, naming both tables; rename one. On a provider without a satellite that scopes names per table, such as MySQL, that rename is one the database would not have needed, and with the differ registered at runtime (`UseComplexIndexes()`) `Migrate()` raises the same error until it is made. A snapshot holding such a name stays diffable.
+
 ## 5.4.0
 
 Fixes to what 5.x already ships, found while testing the packages against EF Core 11 and planning
diff --git a/CLAUDE.md b/CLAUDE.md
index 8452553..73d23a1 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -208,7 +208,7 @@ them with no base to resolve against, so **every link in them must be an absolut
 are condensed on purpose and will overlap `docs/` — that duplication is the price of a package page
 that stands alone, and `DocumentationLinkTests` guards only the part that fails silently.
 
-`ROADMAP.md` at the root is the plan for 5.4.0 and the 6.0 family: the delete guard, the generic
+`ROADMAP.md` at the root is the plan for 5.5.0 and the 6.0 family: the delete guard, the generic
 descriptor differ, the rename under the `CodoMetis.` prefix, the plugin host and EF Core 11. It sits at the
 root on purpose: `DocumentationLinkTests` checks its links, but `DocumentationApiTests` scans only
 `docs/`, so the roadmap may name methods that do not exist yet.
@@ -267,7 +267,7 @@ stored as property annotations) and entity-level `HasComplexIndex(x => x.Complex
 
 Names are validated at **two** levels, because neither alone is sufficient. `AddOrReplace` rejects
 an explicit name already used on the same entity (fast feedback at the declaration), and the
-differ's `ValidateUniqueIndexNames` rejects duplicate resolved names per table — the only place
+differ's `ValidateUniqueIndexNames` rejects duplicate resolved names within the provider's scope (below) — the only place
 that sees across the two stores (property-level annotations vs the entity-level list) and knows the
 *default* names, which depend on resolved column names. It validates the **target model only**: a
 snapshot that already contains a collision must stay diffable, or the model could never be fixed.
@@ -293,8 +293,23 @@ applied clean), and index names per **schema**, where every primary key, unique,
 temporal constraint also owns an index (42P07). A collision is reported only when one party is
 this package's; two of EF's own objects are EF's business. It collects into a list, not a set: the
 two same-named declarations it exists to find produce identical entries, and a set merged them.
-Core's `ValidateUniqueIndexNames` stays per table on purpose — SQL Server scopes index names per
-table.
+
+Where an index name must be unique is a provider fact, declared through
+`CustomMigrationsModelDiffer.IndexNameScope` and applied by both core checks
+(`ValidateUniqueIndexNames`, `ValidateNoNativeIndexNameCollision`): `IndexNameScope.Database` by
+default, `IndexNameScope.Schema` in the PostgreSQL satellite, `IndexNameScope.Table` in the SQL
+Server one. The default is SQLite's rule, and it has to be *database*, not schema: SQLite's provider
+keeps a configured schema in the model but leaves it out of the DDL, so `north.a` and `south.b`
+share one namespace (probed 2026-09-22). Until 5.4.1 both checks were per table everywhere, and the
+SQLite test "the same name on a different table is not a collision" approved a model that
+`sqlite3` rejects with "index … already exists". The widest scope is also the right default for
+providers without a satellite: too wide costs a rename the database did not need (MySQL scopes per
+table), too narrow a failed apply. On PostgreSQL a clash between two plain indexes is therefore
+reported by the core, before `ValidateNamesAcrossKinds` runs; the cross-kind check keeps complex
+indexes in its list for the pairs only it sees — keys, constraint-backed indexes, and a table in the
+unset default schema against one naming `public`, which the core compares as configured. Each
+collision throws once, from whichever check sees it first; do not "deduplicate" by filtering index
+pairs out of the cross-kind check, since it is the only net for the `public` case.
 
 ### The read model is the differ's reader
 
@@ -493,7 +508,7 @@ still skipped silently — an index on those is nothing this package could creat
 
 ### Key extension points
 
-- **Adding a new provider**: Subclass `CustomMigrationsModelDiffer` (override `IsForwardedIndexAnnotation`, optionally `ValidateCreateIndexOperation`/`ResolveUnmappedPart`/`QuoteIdentifier`), implement `IDesignTimeServices` to replace the differ, and ship a `.targets` file that injects the attribute (with `ForProvider` set). The PostgreSQL project is the full-featured reference; the SQL Server project is the minimal one (whitelist + validation, no custom SQL generator).
+- **Adding a new provider**: Subclass `CustomMigrationsModelDiffer` (override `IsForwardedIndexAnnotation` and `IndexNameScope` unless the provider keeps index names unique across the database, optionally `ValidateCreateIndexOperation`/`ResolveUnmappedPart`/`QuoteIdentifier`), implement `IDesignTimeServices` to replace the differ, and ship a `.targets` file that injects the attribute (with `ForProvider` set). The PostgreSQL project is the full-featured reference; the SQL Server project is the minimal one (whitelist + validation, no custom SQL generator).
 - **New index options**: Add constants to `ComplexIndexAnnotations.cs` (or `NpgsqlAnnotations.cs`), expose them via `ComplexIndexBuilder`, and read them in the differ when constructing `CreateIndexOperation`.
 
 ### Expression path extraction
diff --git a/Directory.Build.props b/Directory.Build.props
index 96ef5bb..41f9400 100644
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -1,6 +1,6 @@
 <Project>
     <PropertyGroup>
-        <Version>5.4.0</Version>
+        <Version>5.4.1</Version>
         <Authors>CaffeinatedCoder</Authors>
         <PackageLicenseExpression>MIT</PackageLicenseExpression>
         <GenerateDocumentationFile>true</GenerateDocumentationFile>
@@ -63,7 +63,7 @@
     -->
     <PropertyGroup>
         <EnablePackageValidation>true</EnablePackageValidation>
-        <PackageValidationBaselineVersion>5.3.0</PackageValidationBaselineVersion>
+        <PackageValidationBaselineVersion>5.4.0</PackageValidationBaselineVersion>
     </PropertyGroup>
 
     <!--
diff --git a/README.md b/README.md
index a5f8b31..84c4c38 100644
--- a/README.md
+++ b/README.md
@@ -146,10 +146,12 @@ Selectors also see through a value converter: for a value object mapped as one c
 provided the member's type is the converter's provider type. `x => x.CreatedAt.Year` does not
 resolve, and says so.
 
-Index names must be unique per table, and the package enforces it rather than letting the database
-reject the migration: reusing a name throws at the declaration, and two declarations that resolve to
-the same name — including a property-level and an entity-level index over one column, which share a
-default name — throw during `dotnet ef migrations add`. So does a name longer than the provider's
+Index names must be unique wherever the provider requires — across the whole database on SQLite,
+per schema on PostgreSQL, per table on SQL Server — and the package enforces it rather than letting
+the database reject the migration: reusing a name throws at the declaration, and two declarations
+that resolve to the same name — including a property-level and an entity-level index over one
+column, which share a default name, or a complex and a native index on two SQLite tables — throw
+during `dotnet ef migrations add`. So does a name longer than the provider's
 identifier limit: PostgreSQL would otherwise truncate it to 63 bytes with a NOTICE and apply the
 migration cleanly, leaving the index under a name that no declaration and no constraint-violation
 error ever reports. Default names are checked too, since this package never truncates them.
diff --git a/ROADMAP.md b/ROADMAP.md
index dad843c..3822190 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,4 +1,4 @@
-# Roadmap: 5.4.0, then the 6.0 family
+# Roadmap: 5.5.0, then the 6.0 family
 
 Written 2026-09-19 against 5.3.0. A plan, not a promise: every item is marked **Decided**,
 **Proposed** or **Open**, and the line references are as of 5.3.0 and will rot. The plan answers
@@ -6,6 +6,11 @@ four questions in order: what to ship next on EF Core 10, what to rename the pac
 split them so the next five features do not each add a copy of the differ, and how EF Core 11
 fits in. Sources are collected at the end.
 
+Updated 2026-09-22 with 5.4.1. 5.4.0 and 5.4.1 are fix releases: the 4.0 name registry went out
+in 5.4.0, and everything else planned for 5.4.0 — 4.1 to 4.3 — moves to 5.5.0. The same update
+corrects two claims: the sixth `MigrationsModelDiffer` constructor parameter belongs to EF Core 12,
+not 11, and the temporal annotation constants 4.1 meant to retire are neither public nor dead.
+
 ## 1. Where things stand
 
 **EF Core 11 makes the package name wrong.** `Microsoft.EntityFrameworkCore` 11.0.0-rc.1 was
@@ -25,9 +30,9 @@ years.
 (five parameters), `IMigrationsModelDiffer`, `IMigrationsSqlGenerator`, `CreateIndexOperation`,
 `ITrigger` and `DesignTimeServicesReferenceAttribute` have no diff against 10.0. Two things to
 watch: the protected `GetDefaultValue(Type)` was removed (not overridden here), and a sixth
-constructor parameter, `IDiagnosticsLogger<DbLoggerCategory.Migrations>`, exists on `main` but
-not in any published preview. When it lands, the `base(...)` call in `CustomMigrationsModelDiffer`
-stops compiling on EF Core 11.
+constructor parameter, `IDiagnosticsLogger<DbLoggerCategory.Migrations>`, exists on `main`. That is
+EF Core 12 (12.0.0 alpha); `release/11.0` keeps five parameters (checked 2026-09-22), so the
+`base(...)` call in `CustomMigrationsModelDiffer` compiles unchanged on EF Core 11 and breaks on 12.
 
 **The name covers half of what ships.** Core and the SQL Server package are indexes only. In the
 PostgreSQL package, 2124 source lines are index code and 779 are constraint code, while the
@@ -55,8 +60,8 @@ trigger does not, and is a non-goal.
 
 | # | Decision | Choice | Status |
 |---|---|---|---|
-| D0 | Name-uniqueness validation for temporal constraints | Ship first, before 4.1, as its own fix | Decided |
-| D1 | Where the delete guard ships first | 5.4.0, PostgreSQL package, design-time `SqlOperation`s | Proposed |
+| D0 | Name-uniqueness validation for temporal constraints | Ship first, before 4.1, as its own fix | Shipped in 5.4.0 |
+| D1 | Where the delete guard ships first | 5.5.0, PostgreSQL package, design-time `SqlOperation`s | Proposed |
 | D2 | What precedes it | One generic descriptor differ replacing the four copies | Proposed |
 | D3 | Rename | Yes, at 6.0.0, whole family, new namespaces | Proposed |
 | D4 | The name | Working name `CodoMetis.EFCore.Syntagma`; shortlist in 5.1 (SchemaKit, Beyond, Perissos, Sterigma, Eutaxia) | Open, Ricardo's call |
@@ -72,7 +77,8 @@ trigger does not, and is a non-goal.
 
 ## 3. Release lines and versioning
 
-**5.x (old ids, EF Core 10, `net10.0`).** Receives 5.4.0 with the items in section 4, then fixes.
+**5.x (old ids, EF Core 10, `net10.0`).** Received 4.0 in 5.4.0; receives 5.5.0 with the rest of
+section 4, then fixes.
 After 6.0.0 ships it receives security and data-safety fixes only, until the consumer base has
 moved or EF Core 10 leaves support. The dependency ceiling `[10.0.0, 11.0.0)` stays.
 
@@ -87,8 +93,8 @@ it.
 **Why one stream and not two (D7).** Two streams mean a cherry-pick per fix and a backport
 decision per feature for two years, for one maintainer. Multi-targeting costs a second test run
 and a second SDK on the runner. The differences between the two builds are known and small:
-the constructor parameter above, `IEntityType.FindIndex` widening to `IReadOnlyPropertyBase`
-(source-compatible), and the native-index handover in section 8. They live behind
+`IEntityType.FindIndex` widening to `IReadOnlyPropertyBase` (source-compatible) and the
+native-index handover in section 8. They live behind
 `NET11_0_OR_GREATER`.
 
 **Branching.** `main` carries 6.x; `support/5.x` carries the old line. `release.yml` verifies the
@@ -96,9 +102,9 @@ tag against `Directory.Build.props` on the tagged commit and discovers packages
 output, so both branches release unchanged. Branch protection and the required `Test
 (ubuntu-latest)` check have to be configured on `support/5.x` by hand.
 
-## 4. Phase 1: 5.4.0 on EF Core 10
+## 4. Phase 1: 5.5.0 on EF Core 10
 
-### 4.0 Fix first: constraint names are not validated for the temporal kinds (D0)
+### 4.0 Fix first: constraint names are not validated for the temporal kinds (D0, shipped in 5.4.0)
 
 Indexes are checked by `ValidateUniqueIndexNames` and against native `HasIndex` names, exclusion
 constraints by `ValidateUniqueExclusionNames`. Temporal unique constraints and temporal foreign keys
@@ -108,8 +114,8 @@ exclusion constraint on the same table, scaffold cleanly and fail at apply time
 a `UNIQUE … WITHOUT OVERLAPS` constraint is backed by an index of the same name, and index names
 share the schema's relation namespace, so a temporal constraint named like any index in the schema
 fails with 42P07. This is the signature failure this repository exists to catch, and it is
-independent of everything else in the plan, so it ships first, as 5.3.1 or the first commit of
-5.4.0.
+independent of everything else in the plan, so it shipped first, in 5.4.0, as the Npgsql differ's
+`ValidateNamesAcrossKinds`.
 
 The fix: one name registry per target model, filled by all four kinds plus the native indexes and
 native constraints of the same table or schema, with the rule per kind: foreign keys are unique per
@@ -120,6 +126,11 @@ declarations and their kinds. Tests: each collision pair throws; a same-named pa
 tables passes for the per-table kinds; the snapshot side is left alone; `verify-the-guard` by
 reverting. Once 4.1 lands the registry becomes the generic differ's `Validate` hook.
 
+5.4.1 fixed the core's side of the same problem: its index-name checks were per table on every
+provider, while SQLite keeps index names unique across the database. The scope is now a provider
+virtual, `IndexNameScope` (database by default, schema on PostgreSQL, table on SQL Server), and the
+generic differ's name validation has to honour it for every kind it takes over.
+
 ### 4.1 One descriptor differ instead of four
 
 Four copies of the same algorithm exist today: complex indexes in
@@ -173,10 +184,12 @@ refactor itself; one characterisation test that declares all four kinds on one m
 the full operation order is worth adding before starting, since `OperationOrderingTests` covers
 pairs.
 
-Riding along: `NpgsqlTemporalAnnotations.WithoutOverlaps`, `ForeignKeyDependentPeriod` and
-`ForeignKeyPrincipalPeriod` are dead since 5.0.2 (the differ renders `SqlOperation`s and never
-writes them). They are public constants, so removing them is a CP0002 break; mark them
-`[Obsolete]` in 5.4.0 and remove them in 6.0.0.
+Not riding along, though an earlier draft planned it: `NpgsqlTemporalAnnotations.WithoutOverlaps`,
+`ForeignKeyDependentPeriod` and `ForeignKeyPrincipalPeriod` stay. The differ has not written them
+since 5.0.2, but `NpgsqlComplexIndexSqlGenerator` still reads them to render migrations scaffolded
+before 5.0.2, and the class is internal, so there is no CP0002 break to schedule and nothing to mark
+`[Obsolete]`. Removing them would give a fresh database built from those migrations a plain
+`UNIQUE` or foreign key without the period, and it would apply cleanly.
 
 ### 4.2 Delete constraints on PostgreSQL
 
@@ -246,7 +259,7 @@ CREATE TRIGGER "RC_Invoices_Finalized"
   `TRUNCATE` bypasses row triggers; a `BEFORE TRUNCATE` statement trigger is section 6.
 
 **Storage and identity.** `CustomRowConstraint:Constraints`, a JSON list on the entity type,
-serialised like `ExclusionConstraintDefinition`. `RowConstraintDefinition`: `Event` (delete only in 5.4, the field exists
+serialised like `ExclusionConstraintDefinition`. `RowConstraintDefinition`: `Event` (delete only in 5.5, the field exists
 so update and truncate are additive), `Predicate` (template or null), `Name`, `Message`. Identity
 for the store is event plus predicate; a redeclaration replaces, two guards with different
 predicates coexist and both need names, an explicit name reused on the entity is rejected.
@@ -284,9 +297,8 @@ migration; this is a second PostgreSQL-only discriminator next to the exclusion
 reading "no", entries in the root and PostgreSQL changelogs, a CLAUDE.md architecture paragraph, and
 a `migration-safety-review` checklist item for row constraints.
 
-### 4.3 Small items riding along in 5.4.0
+### 4.3 Small items riding along in 5.5.0
 
-- The `[Obsolete]` markings from 4.1.
 - `RuntimeWiringSentinel` is `"__requires_UseNpgsqlComplexIndexes__"` and lives in core. Leave the
   value (it is in consumers' migrations) and move the choice of value behind a provider virtual in
   6.0 (section 5.4).
@@ -336,7 +348,7 @@ typed filters, and more."
 Two identifiers outlive any product name because they land in consumers' snapshots and
 migrations: annotation keys and the shared trigger functions. Both are branded with the owner
 prefix, never the product: annotations under `CodoMetis:` from 6.0 (5.5), and functions such as
-`codometis_row_constraint()` from 5.4.0. That settles the permanence question in 4.2 regardless
+`codometis_row_constraint()` from 5.5.0. That settles the permanence question in 4.2 regardless
 of D4.
 
 The declaration API keeps its names (`HasComplexIndex`, `HasExpressionIndex`,
@@ -503,9 +515,9 @@ second consumer per satellite in the smoke test once `net11.0` exists.
 3. Replace `UseNpgsqlComplexIndexes()` / `UseSqlServerComplexIndexes()` / `UseComplexIndexes()`
    with the provider-builder form in 5.6.
 4. Run `dotnet ef migrations add`; expect one migration containing only the snapshot rewrite (5.5).
-5. Removed: the three obsolete temporal constants; the pre-5.0.2 temporal operation overrides in
-   the generator and the legacy `PropertyPaths` snapshot form are **kept**, because consumers
-   replay old migrations on fresh databases forever.
+5. Nothing an old migration needs is removed: the pre-5.0.2 temporal operation overrides in the
+   generator, the three annotation keys they read, and the legacy `PropertyPaths` snapshot form are
+   **kept**, because consumers replay old migrations on fresh databases forever.
 
 ## 6. Phase 3: the 6.x feature backlog, ordered by reuse
 
@@ -705,8 +717,9 @@ the templates in 7.5 are in.
   `HasIndex` over the same complex-type path scaffolds nothing instead of drop-and-create, and the
   native-collision check learns the difference between "same index, moved" and "two indexes, one
   name". Same for `WITHOUT OVERLAPS` and `PERIOD` against Npgsql 11.
-- **Constructor.** `#if NET11_0_OR_GREATER` around the differ constructor for the sixth parameter,
-  the day it ships.
+- **Constructor.** Nothing to do for EF Core 11: `release/11.0` keeps the five-parameter
+  constructor, and a `net10.0;net11.0` spike build (2026-09-22) needed no source change. The sixth parameter
+  is EF Core 12's, and belongs to whichever 6.x adds that target.
 - **Snapshot generator.** `CSharpSnapshotGenerator` was refactored in rc.1 (parameters object,
   centralised annotation handling, complex-collection branch). Not subclassed here, but the
   round-trip fixtures must be regenerated on the `net11.0` run.
@@ -717,9 +730,9 @@ the templates in 7.5 are in.
 - **D4 is Ricardo's call.** The document uses `Syntagma` as a working name; every candidate in
   5.1 reads the same, and the rename is mechanical.
 - **The shared function's name is permanent** once a consumer's migration carries it (4.2); it is
-  owner-branded, so D4 does not gate 5.4.0.
-- **Name-uniqueness for temporal kinds** (4.0) is a behaviour change on a model that already fails
-  at apply time. Changelog it as a fix.
+  owner-branded, so D4 does not gate 5.5.0.
+- **Name-uniqueness for temporal kinds** (4.0) was a behaviour change on a model that already
+  failed at apply time, and shipped in 5.4.0 as a fix.
 - **Snapshot v2** produces one empty migration per consumer (5.5). A consumer with a CI gate on
   `has-pending-model-changes` sees it fail once after upgrading; the migration guide has to say so
   up front.
@@ -736,9 +749,9 @@ the templates in 7.5 are in.
 
 | Step | Line | Content | Gate |
 |---|---|---|---|
-| 0 | 5.3.1 or 5.4.0 | Constraint-name registry across all kinds and native names (4.0) | `verify-the-guard` on each collision pair |
-| 1 | 5.4.0 | Characterisation test for four-kind ordering; generic descriptor differ; `[Obsolete]` constants | Suite green after each kind moves |
-| 2 | 5.4.0 | Delete constraint on PostgreSQL, docs, smoke-test discriminator | Integration test, `verify-the-guard` on every validation |
+| 0 | 5.4.0, 5.4.1 (shipped) | Constraint-name registry across all kinds and native names (4.0); core index names in the provider's namespace | `verify-the-guard` on each collision pair |
+| 1 | 5.5.0 | Characterisation test for four-kind ordering; generic descriptor differ | Suite green after each kind moves |
+| 2 | 5.5.0 | Delete constraint on PostgreSQL, docs, smoke-test discriminator | Integration test, `verify-the-guard` on every validation |
 | 3 | pre-6.0 | D4 settled; trusted-publishing scope checked for the new ids; repository renamed | nuget.org confirmations |
 | 4 | 6.0.0 | Rename and split; plugin host; dialect; translator move; snapshot v2; old-package guard; convention tests; migration guide | Smoke test on both providers from a cold cache; snapshot fixture from 5.x |
 | 5 | post-6.0 | Deprecate the old ids with the alternate; `support/5.x` branch protection | |
diff --git a/src/EFCore.ComplexIndexes.PostgreSQL/NpgsqlComplexIndexMigrationsModelDiffer.cs b/src/EFCore.ComplexIndexes.PostgreSQL/NpgsqlComplexIndexMigrationsModelDiffer.cs
index 2600524..abda80a 100644
--- a/src/EFCore.ComplexIndexes.PostgreSQL/NpgsqlComplexIndexMigrationsModelDiffer.cs
+++ b/src/EFCore.ComplexIndexes.PostgreSQL/NpgsqlComplexIndexMigrationsModelDiffer.cs
@@ -76,6 +76,14 @@ protected override bool IsForwardedIndexAnnotation(string annotationName)
     /// <summary>PostgreSQL renames indexes standalone (<c>ALTER INDEX … RENAME TO</c>).</summary>
     protected override bool CanRenameIndexes => true;
 
+    /// <summary>
+    /// PostgreSQL keeps index names unique among the relations of a schema, so the core's own checks
+    /// already reject two complex indexes, or a complex and a native index, sharing a name anywhere
+    /// in one schema. Everything else PostgreSQL shares that namespace with is left to
+    /// <c>ValidateNamesAcrossKinds</c>.
+    /// </summary>
+    protected override IndexNameScope IndexNameScope => IndexNameScope.Schema;
+
     /// <summary>
     /// PostgreSQL's identifier limit (<c>NAMEDATALEN - 1</c>, 63) is a byte count: a name made of
     /// non-ASCII characters hits it well before its 63rd character.
@@ -378,6 +386,13 @@ public override IReadOnlyList<MigrationOperation> GetDifferences(
     /// schema, scaffolded cleanly. Collisions between two of EF Core's own objects are not this
     /// package's to police. Target model only: a snapshot that already holds a collision must stay
     /// diffable, or the model could never be fixed.
+    /// <para>
+    /// A complex index clashing with another complex index or a native one never gets this far: the
+    /// core rejects it first under <see cref="IndexNameScope"/>, with a message naming both
+    /// declarations. Complex indexes stay in the list for the pairs only this check sees — against a
+    /// key or a constraint's index, and a table left in the default schema against one that names
+    /// <c>public</c> explicitly — so each collision is reported once, by whichever check sees it first.
+    /// </para>
     /// </remarks>
     private void ValidateNamesAcrossKinds(IRelationalModel? target)
     {
diff --git a/src/EFCore.ComplexIndexes.SqlServer/CHANGELOG.md b/src/EFCore.ComplexIndexes.SqlServer/CHANGELOG.md
index ca8cb65..5b1fc5e 100644
--- a/src/EFCore.ComplexIndexes.SqlServer/CHANGELOG.md
+++ b/src/EFCore.ComplexIndexes.SqlServer/CHANGELOG.md
@@ -4,6 +4,12 @@ Changes to the SQL Server satellite, newest first. The
 [root changelog](https://github.com/CaffeinatedCoder/EFCore.ComplexIndexes/blob/main/CHANGELOG.md)
 covers all three packages.
 
+## 5.4.1
+
+- **Changed:** the differ declares SQL Server's index-name scope, per table, now that the core
+  checks names across the whole database by default. Two tables may still carry indexes of the same
+  name, complex or native; a name reused on one table is rejected as before.
+
 ## 5.2.0
 
 - **New:** filters resolve `{Property.Path}` placeholders to the mapped column, bracket-quoted, at
diff --git a/src/EFCore.ComplexIndexes.SqlServer/SqlServerComplexIndexMigrationsModelDiffer.cs b/src/EFCore.ComplexIndexes.SqlServer/SqlServerComplexIndexMigrationsModelDiffer.cs
index 52ab9c8..3cad02b 100644
--- a/src/EFCore.ComplexIndexes.SqlServer/SqlServerComplexIndexMigrationsModelDiffer.cs
+++ b/src/EFCore.ComplexIndexes.SqlServer/SqlServerComplexIndexMigrationsModelDiffer.cs
@@ -53,6 +53,12 @@ protected override bool IsForwardedIndexAnnotation(string annotationName)
     /// <summary>SQL Server renames indexes standalone (<c>sp_rename</c>).</summary>
     protected override bool CanRenameIndexes => true;
 
+    /// <summary>
+    /// SQL Server keeps index names unique per table, so two tables may each carry an index of the
+    /// same name.
+    /// </summary>
+    protected override IndexNameScope IndexNameScope => IndexNameScope.Table;
+
     /// <summary>SQL Server delimits identifiers with brackets.</summary>
     protected override string QuoteIdentifier(string identifier)
         => "[" + identifier.Replace("]", "]]") + "]";
diff --git a/src/EFCore.ComplexIndexes/CHANGELOG.md b/src/EFCore.ComplexIndexes/CHANGELOG.md
index c094803..f717590 100644
--- a/src/EFCore.ComplexIndexes/CHANGELOG.md
+++ b/src/EFCore.ComplexIndexes/CHANGELOG.md
@@ -4,6 +4,18 @@ Changes to the core package, newest first. The
 [root changelog](https://github.com/CaffeinatedCoder/EFCore.ComplexIndexes/blob/main/CHANGELOG.md)
 covers all three packages.
 
+## 5.4.1
+
+- **Fixed:** complex index names are checked where the provider keeps them unique, not always
+  per table. The core's scope is the whole database — SQLite's rule: it rejects a second
+  `CREATE INDEX` under a name used on any other table and ignores configured schemas — so two tables
+  sharing an index name no longer scaffold cleanly and fail when applied. On a provider without a
+  satellite that scopes names per table (MySQL), the check asks for a rename the database would not
+  have needed.
+- **New:** the `IndexNameScope` enum and the protected `CustomMigrationsModelDiffer.IndexNameScope`
+  property, through which a provider's differ declares where its index names must be unique
+  (`Table`, `Schema` or `Database`, the default).
+
 ## 5.4.0
 
 - **New:** `ComplexIndexAnnotations.RenderingVersion`, written onto the model by every index
diff --git a/src/EFCore.ComplexIndexes/CustomMigrationsModelDiffer.cs b/src/EFCore.ComplexIndexes/CustomMigrationsModelDiffer.cs
index 776f50a..381f7ea 100644
--- a/src/EFCore.ComplexIndexes/CustomMigrationsModelDiffer.cs
+++ b/src/EFCore.ComplexIndexes/CustomMigrationsModelDiffer.cs
@@ -20,8 +20,8 @@ namespace EFCore.ComplexIndexes;
 /// <remarks>
 /// Registered through <see cref="CustomDesignTimeServices"/>, which the packaged <c>.targets</c> file
 /// wires up automatically — consumers do not construct this type. Providers extend it by overriding
-/// <c>IsForwardedIndexAnnotation</c>, <c>ValidateCreateIndexOperation</c>, <c>ResolveUnmappedPart</c>
-/// and <c>ResolveTemplatePart</c>.
+/// <c>IsForwardedIndexAnnotation</c>, <c>IndexNameScope</c>, <c>ValidateCreateIndexOperation</c>,
+/// <c>ResolveUnmappedPart</c> and <c>ResolveTemplatePart</c>.
 /// </remarks>
 /// <param name="typeMappingSource">EF Core relational type mapping source.</param>
 /// <param name="migrationsAnnotationProvider">EF Core migrations annotation provider.</param>
@@ -254,6 +254,22 @@ protected virtual void ValidateCreatedIndexes(IReadOnlyList<CreateIndexOperation
     /// </summary>
     protected virtual bool CanRenameIndexes => false;
 
+    /// <summary>
+    /// Where the provider requires index names to be unique, which decides what a complex index
+    /// name is checked against at <c>migrations add</c>. The core default is
+    /// <see cref="EFCore.ComplexIndexes.IndexNameScope.Database"/>, SQLite's rule: SQLite rejects a
+    /// second <c>CREATE INDEX</c> under a name used on any other table, and ignores the schemas a
+    /// model configures. The SQL Server satellite narrows it to
+    /// <see cref="EFCore.ComplexIndexes.IndexNameScope.Table"/>, the PostgreSQL one to
+    /// <see cref="EFCore.ComplexIndexes.IndexNameScope.Schema"/>.
+    /// </summary>
+    /// <remarks>
+    /// The core also serves providers without a satellite, and the default is the widest scope on
+    /// purpose: on a provider that scopes names more narrowly it costs a rename the database would
+    /// not have needed, where a narrower default approves a migration that fails when applied.
+    /// </remarks>
+    protected virtual IndexNameScope IndexNameScope => IndexNameScope.Database;
+
     /// <summary>
     /// Decides whether a property-level annotation is carried onto the emitted
     /// <see cref="CreateIndexOperation"/> as a provider index option. The core package forwards
@@ -504,29 +520,37 @@ protected virtual string QuoteIdentifier(string identifier)
         => "\"" + identifier.Replace("\"", "\"\"") + "\"";
 
     /// <summary>
-    /// Fails when two distinct declarations resolve to the same index name on the same table.
+    /// Fails when two distinct declarations resolve to the same index name within the provider's
+    /// <see cref="IndexNameScope"/>.
     /// </summary>
     /// <remarks>
     /// Such a pair emits two <c>CREATE INDEX</c> statements under one name — a migration that
-    /// scaffolds happily and then fails at apply time (PostgreSQL 42P07). This is the first point
-    /// where the collision is visible: the two stores (per-property annotations and the entity-level
+    /// scaffolds happily and then fails at apply time (PostgreSQL 42P07; SQLite "index … already
+    /// exists", even when the two sit on different tables). This is the first point where the
+    /// collision is visible: the two stores (per-property annotations and the entity-level
     /// definition list) cannot see each other, and default names are only known once property paths
     /// have been resolved to real columns. Identical declarations are already collapsed by the
     /// descriptor set, so only genuinely different indexes reach this check.
     /// </remarks>
-    private static void ValidateUniqueIndexNames(HashSet<IndexDescriptor> descriptors)
+    private void ValidateUniqueIndexNames(HashSet<IndexDescriptor> descriptors)
     {
         var collision = descriptors
-                       .GroupBy(d => (d.TableName, d.Schema, d.IndexName))
+                       .GroupBy(d => NameKey(d.TableName, d.Schema, d.IndexName))
                        .FirstOrDefault(g => g.Count() > 1);
 
         if (collision is null)
             return;
 
+        var members  = collision.ToList();
+        var oneTable = members.All(d => d.TableName == members[0].TableName);
+
         throw new InvalidOperationException(
-            $"Two complex indexes on table '{collision.Key.TableName}' both resolve to the name "
-          + $"'{collision.Key.IndexName}': {string.Join(" and ", collision.Select(Describe))}. "
-          + "Index names must be unique per table — give each declaration an explicit, distinct name.");
+            (oneTable
+                 ? $"Two complex indexes on table '{members[0].TableName}' both resolve to the name '{members[0].IndexName}': "
+                 + string.Join(" and ", members.Select(Describe))
+                 : $"Two complex indexes both resolve to the name '{members[0].IndexName}': "
+                 + string.Join(" and ", members.Select(d => $"{Describe(d)} on table '{d.TableName}'")))
+          + $". {UniquenessRule(oneTable)} — give each declaration an explicit, distinct name.");
 
         static string Describe(IndexDescriptor descriptor)
         {
@@ -537,21 +561,23 @@ static string Describe(IndexDescriptor descriptor)
     }
 
     /// <summary>
-    /// Fails when a complex index resolves to the name of a native <c>HasIndex</c> on the same table.
+    /// Fails when a complex index resolves to the name of a native <c>HasIndex</c> within the
+    /// provider's <see cref="IndexNameScope"/>.
     /// </summary>
     /// <remarks>
     /// The base differ emits the native index and this differ emits the complex one, neither seeing
     /// the other, so the migration scaffolded two <c>CREATE INDEX</c> statements under one name and
     /// failed at apply time (PostgreSQL 42P07). Only the target model's native indexes are consulted:
     /// an index <em>moving</em> between a native declaration and a complex one under the same name
-    /// is a legitimate drop-and-create, not a collision, and must keep diffing.
+    /// is a legitimate drop-and-create, not a collision, and must keep diffing. Two native indexes
+    /// sharing a name are EF Core's to report, not this package's.
     /// </remarks>
-    private static void ValidateNoNativeIndexNameCollision(IRelationalModel? target, HashSet<IndexDescriptor> descriptors)
+    private void ValidateNoNativeIndexNameCollision(IRelationalModel? target, HashSet<IndexDescriptor> descriptors)
     {
         if (target is null || descriptors.Count == 0)
             return;
 
-        var native = new Dictionary<(string Table, string? Schema, string Name), string>();
+        var native = new Dictionary<(string? Schema, string? Table, string Name), (string Table, string Properties)>();
 
         foreach (var entityType in target.Model.GetEntityTypes())
         {
@@ -568,23 +594,42 @@ private static void ValidateNoNativeIndexNameCollision(IRelationalModel? target,
                 var name = index.GetDatabaseName(storeObject);
                 if (name is null) continue;
 
-                native.TryAdd((tableName, schema, name), string.Join(", ", index.Properties.Select(p => p.Name)));
+                native.TryAdd(NameKey(tableName, schema, name), (tableName, string.Join(", ", index.Properties.Select(p => p.Name))));
             }
         }
 
         foreach (var descriptor in descriptors)
         {
-            if (!native.TryGetValue((descriptor.TableName, descriptor.Schema, descriptor.IndexName), out var properties))
+            if (!native.TryGetValue(NameKey(descriptor.TableName, descriptor.Schema, descriptor.IndexName), out var other))
                 continue;
 
+            var where = other.Table == descriptor.TableName ? "" : $" on table '{other.Table}'";
+
             throw new InvalidOperationException(
                 $"The complex index '{descriptor.IndexName}' on table '{descriptor.TableName}' has the same name as "
-              + $"the native index on ({properties}) declared with HasIndex. Index names must be unique per table — "
+              + $"the native index on ({other.Properties}) declared with HasIndex{where}. {UniquenessRule(where == "")} — "
               + "the migration would scaffold two CREATE INDEX statements under one name and fail when applied. "
               + "Give one of them a different name.");
         }
     }
 
+    // Two index names clash exactly when their keys are equal: the parts outside the provider's
+    // scope are blanked out.
+    private (string? Schema, string? Table, string Name) NameKey(string table, string? schema, string name)
+        => IndexNameScope switch
+           {
+               IndexNameScope.Table  => (schema, table, name),
+               IndexNameScope.Schema => (schema, null, name),
+               _                     => (null, null, name)
+           };
+
+    private string UniquenessRule(bool sameTable) => (sameTable, IndexNameScope) switch
+    {
+        (true, _)                     => "Index names must be unique per table",
+        (_, IndexNameScope.Schema)    => "Index names must be unique per schema here, not just per table",
+        _                             => "Index names must be unique across the database here, not just per table or schema"
+    };
+
     /// <summary>
     /// Fails when a non-unique index leads with a JSON member that had to fall back to text.
     /// </summary>
diff --git a/src/EFCore.ComplexIndexes/IndexNameScope.cs b/src/EFCore.ComplexIndexes/IndexNameScope.cs
new file mode 100644
index 0000000..5546b9d
--- /dev/null
+++ b/src/EFCore.ComplexIndexes/IndexNameScope.cs
@@ -0,0 +1,21 @@
+namespace EFCore.ComplexIndexes;
+
+/// <summary>
+/// The namespace in which a provider requires index names to be unique. A differ checks every
+/// complex index name against this scope at <c>migrations add</c>, because a name reused inside it
+/// scaffolds cleanly and only fails when the migration is applied.
+/// </summary>
+public enum IndexNameScope
+{
+    /// <summary>Unique among the indexes of one table — SQL Server, MySQL.</summary>
+    Table,
+
+    /// <summary>Unique among all relations of one schema — PostgreSQL.</summary>
+    Schema,
+
+    /// <summary>
+    /// Unique across the whole database, whatever schema a table is configured with — SQLite, whose
+    /// provider keeps a configured schema in the model but leaves it out of the DDL.
+    /// </summary>
+    Database
+}
diff --git a/src/EFCore.ComplexIndexes/README.md b/src/EFCore.ComplexIndexes/README.md
index c0305f0..0dee5ee 100644
--- a/src/EFCore.ComplexIndexes/README.md
+++ b/src/EFCore.ComplexIndexes/README.md
@@ -55,8 +55,9 @@ builder.HasComplexIndex(x => x.EmailAddress.Value,
     indexName: "ix_person_email_all");
 ```
 
-Index names must be unique per table and within the provider's identifier limit (63 bytes on
-PostgreSQL, which would otherwise truncate silently), and the package enforces both at
+Index names must be unique wherever the provider requires (across the database on SQLite, per
+schema on PostgreSQL, per table on SQL Server) and within the provider's identifier limit (63 bytes
+on PostgreSQL, which would otherwise truncate silently), and the package enforces both at
 `dotnet ef migrations add` rather than letting the database reject — or quietly shorten — the name.
 
 ### Composite index across scalar and nested properties
diff --git a/test/EFCore.ComplexIndexes.Tests/IndexNameCollisionTests.cs b/test/EFCore.ComplexIndexes.Tests/IndexNameCollisionTests.cs
index 0566adb..bc903b7 100644
--- a/test/EFCore.ComplexIndexes.Tests/IndexNameCollisionTests.cs
+++ b/test/EFCore.ComplexIndexes.Tests/IndexNameCollisionTests.cs
@@ -1,13 +1,19 @@
+using Microsoft.Data.Sqlite;
 using Microsoft.EntityFrameworkCore;
+using Microsoft.EntityFrameworkCore.Infrastructure;
+using Microsoft.EntityFrameworkCore.Migrations;
 using Microsoft.EntityFrameworkCore.Migrations.Operations;
 
 namespace EFCore.ComplexIndexes.Tests;
 
 /// <summary>
-/// A complex index and a native <c>HasIndex</c> on the same table can resolve to the same name. The
-/// base differ emits one and this differ the other, neither seeing the other, so the migration
-/// scaffolded two <c>CREATE INDEX</c> statements under one name and failed at apply time (42P07).
-/// The differ's own name check only compared complex indexes with each other.
+/// A complex index can resolve to a name already taken by another complex index or a native
+/// <c>HasIndex</c>. The base differ emits one and this differ the other, neither seeing the other, so
+/// the migration scaffolded two <c>CREATE INDEX</c> statements under one name and failed at apply
+/// time (42P07). Where a name is taken depends on the provider: SQLite keeps index names unique
+/// across the database and ignores configured schemas, PostgreSQL per schema, SQL Server per table.
+/// The check used to be per table everywhere, so on SQLite two tables sharing an index name
+/// scaffolded cleanly and failed with "index … already exists".
 /// </summary>
 [TestClass]
 public class IndexNameCollisionTests
@@ -45,8 +51,8 @@ protected override void OnModelCreating(ModelBuilder modelBuilder) =>
             });
     }
 
-    // Same name on a different table is not a collision.
-    private class SeparateTablesContext(DbContextOptions<SeparateTablesContext> options) : DbContext(options)
+    // A native index on one table, a complex index of the same name on another.
+    private class NativeOnAnotherTableContext(DbContextOptions<NativeOnAnotherTableContext> options) : DbContext(options)
     {
         public DbSet<Person>  People    => Set<Person>();
         public DbSet<Company> Companies => Set<Company>();
@@ -70,6 +76,72 @@ protected override void OnModelCreating(ModelBuilder modelBuilder)
         }
     }
 
+    // Two complex indexes of one name, on two tables — in two schemas when asked to be.
+    private class ComplexOnTwoTablesContext(DbContextOptions options) : DbContext(options)
+    {
+        protected virtual string? PeopleSchema     => null;
+        protected virtual string? CompanySchema    => null;
+        protected virtual string  CompanyIndexName => "IX_name";
+
+        public DbSet<Person>  People    => Set<Person>();
+        public DbSet<Company> Companies => Set<Company>();
+
+        protected override void OnModelCreating(ModelBuilder modelBuilder)
+        {
+            modelBuilder.Entity<Company>(b =>
+            {
+                b.ToTable("companies", CompanySchema);
+                b.HasKey(x => x.Id);
+                b.HasComplexIndex(x => x.Name, indexName: CompanyIndexName);
+            });
+
+            modelBuilder.Entity<Person>(b =>
+            {
+                b.ToTable("people", PeopleSchema);
+                b.HasKey(x => x.Id);
+                b.ComplexProperty(x => x.Email);
+                b.HasComplexIndex(x => x.Email.Value, indexName: "IX_name");
+            });
+        }
+    }
+
+    private class ComplexInTwoSchemasContext(DbContextOptions<ComplexInTwoSchemasContext> options) : ComplexOnTwoTablesContext(options)
+    {
+        protected override string PeopleSchema  => "north";
+        protected override string CompanySchema => "south";
+    }
+
+    private class ComplexOnTwoTablesFixedContext(DbContextOptions<ComplexOnTwoTablesFixedContext> options) : ComplexOnTwoTablesContext(options)
+    {
+        protected override string CompanyIndexName => "IX_company_name";
+    }
+
+    // Two of EF Core's own indexes share a name; the complex index is named apart.
+    private class NativeOnlyCollisionContext(DbContextOptions<NativeOnlyCollisionContext> options) : DbContext(options)
+    {
+        public DbSet<Person>  People    => Set<Person>();
+        public DbSet<Company> Companies => Set<Company>();
+
+        protected override void OnModelCreating(ModelBuilder modelBuilder)
+        {
+            modelBuilder.Entity<Company>(b =>
+            {
+                b.ToTable("companies");
+                b.HasKey(x => x.Id);
+                b.HasIndex(x => x.Name).HasDatabaseName("IX_shared");
+            });
+
+            modelBuilder.Entity<Person>(b =>
+            {
+                b.ToTable("people");
+                b.HasKey(x => x.Id);
+                b.HasIndex(x => x.Name).HasDatabaseName("IX_shared");
+                b.ComplexProperty(x => x.Email);
+                b.HasComplexIndex(x => x.Email.Value, indexName: "IX_email");
+            });
+        }
+    }
+
     // The handover shape: the index used to be native and is now complex, under one name.
     private class NativeBeforeContext(DbContextOptions<NativeBeforeContext> options) : DbContext(options)
     {
@@ -99,6 +171,11 @@ protected override void OnModelCreating(ModelBuilder modelBuilder) =>
             });
     }
 
+    private static List<string> CreatedTables(IReadOnlyList<MigrationOperation> operations, string indexName)
+        => [.. operations.OfType<CreateIndexOperation>().Where(o => o.Name == indexName).Select(o => o.Table)];
+
+    // ── Same table: a collision on every provider ──
+
     [TestMethod(DisplayName = "A complex index named like a native HasIndex on the same table is rejected at migrations add")]
     public void Collision_with_native_index_throws()
     {
@@ -109,6 +186,7 @@ public void Collision_with_native_index_throws()
         StringAssert.Contains(exception.Message, "IX_dup");
         StringAssert.Contains(exception.Message, "HasIndex");
         StringAssert.Contains(exception.Message, "Name");
+        StringAssert.Contains(exception.Message, "unique per table");
     }
 
     [TestMethod(DisplayName = "The satellite differs inherit the check")]
@@ -119,15 +197,101 @@ public void Collision_is_rejected_by_the_npgsql_differ()
         Assert.ThrowsExactly<InvalidOperationException>(() => MigrationHarness.NpgsqlDiff(null, target));
     }
 
-    [TestMethod(DisplayName = "The same name on a different table is not a collision")]
-    public void Same_name_on_another_table_is_fine()
+    [TestMethod(DisplayName = "SQL Server rejects a same-named native and complex index on one table")]
+    public void Collision_is_rejected_by_the_sql_server_differ()
+    {
+        var target = MigrationHarness.SqlServerModel<CollisionContext>();
+
+        var exception = Assert.ThrowsExactly<InvalidOperationException>(() => MigrationHarness.SqlServerDiff(null, target));
+
+        StringAssert.Contains(exception.Message, "IX_dup");
+        StringAssert.Contains(exception.Message, "unique per table");
+    }
+
+    // ── Core over SQLite: one namespace for the whole database ──
+
+    // The premise behind IndexNameScope.Database, against what a consumer actually runs: EF's SQLite
+    // generator, which leaves the schemas out of the DDL, and the engine bundled with
+    // Microsoft.Data.Sqlite rather than the sqlite3 CLI. Passes with or without the fix.
+    [TestMethod(DisplayName = "SQLite itself rejects one index name on two tables, whatever their schemas")]
+    public void Sqlite_engine_rejects_one_index_name_on_two_tables()
+    {
+        using var connection = new SqliteConnection(MigrationHarness.SqliteConnection);
+        connection.Open();
+        using var context = new MigrationHarness.EmptyContext(MigrationHarness.SqliteOptions(connection));
+
+        var migration = new MigrationBuilder("Microsoft.EntityFrameworkCore.Sqlite");
+        migration.CreateTable("a", t => new { x = t.Column<string>() }, schema: "north");
+        migration.CreateTable("b", t => new { x = t.Column<string>() }, schema: "south");
+        migration.CreateIndex("IX_name", "a", "x", schema: "north");
+        migration.CreateIndex("IX_name", "b", "x", schema: "south");
+
+        var commands = context.GetService<IMigrationsSqlGenerator>().Generate(migration.Operations);
+
+        var exception = Assert.ThrowsExactly<SqliteException>(() =>
+        {
+            foreach (var command in commands)
+            {
+                using var sql = connection.CreateCommand();
+                sql.CommandText = command.CommandText;
+                sql.ExecuteNonQuery();
+            }
+        });
+
+        StringAssert.Contains(exception.Message, "index IX_name already exists");
+    }
+
+    [TestMethod(DisplayName = "SQLite: a complex index named like a native index on another table is rejected")]
+    public void Sqlite_rejects_native_name_on_another_table()
+    {
+        var target = MigrationHarness.SqliteModel<NativeOnAnotherTableContext>();
+
+        var exception = Assert.ThrowsExactly<InvalidOperationException>(() => MigrationHarness.CoreDiff(null, target));
+
+        StringAssert.Contains(exception.Message, "'IX_name' on table 'people'");
+        StringAssert.Contains(exception.Message, "on table 'companies'");
+        StringAssert.Contains(exception.Message, "unique across the database");
+    }
+
+    [TestMethod(DisplayName = "SQLite: two complex indexes with one name on different tables are rejected")]
+    public void Sqlite_rejects_complex_name_on_another_table()
+    {
+        var target = MigrationHarness.SqliteModel<ComplexOnTwoTablesContext>();
+
+        var exception = Assert.ThrowsExactly<InvalidOperationException>(() => MigrationHarness.CoreDiff(null, target));
+
+        StringAssert.Contains(exception.Message, "both resolve to the name 'IX_name'");
+        StringAssert.Contains(exception.Message, "on table 'companies'");
+        StringAssert.Contains(exception.Message, "on table 'people'");
+    }
+
+    // SQLite's provider keeps a configured schema in the model and leaves it out of the DDL, so
+    // both indexes land in one database: checking per schema would miss this.
+    [TestMethod(DisplayName = "SQLite: tables in different schemas still share one index namespace")]
+    public void Sqlite_ignores_schemas()
     {
-        var target = MigrationHarness.SqliteModel<SeparateTablesContext>();
+        var target = MigrationHarness.SqliteModel<ComplexInTwoSchemasContext>();
 
-        var creates = MigrationHarness.CoreDiff(null, target).OfType<CreateIndexOperation>().Where(o => o.Name == "IX_name").ToList();
+        Assert.ThrowsExactly<InvalidOperationException>(() => MigrationHarness.CoreDiff(null, target));
+    }
+
+    [TestMethod(DisplayName = "SQLite: two of EF Core's own indexes sharing a name are left to EF Core")]
+    public void Sqlite_native_only_collision_is_not_reported()
+    {
+        var target = MigrationHarness.SqliteModel<NativeOnlyCollisionContext>();
+
+        Assert.HasCount(1, CreatedTables(MigrationHarness.CoreDiff(null, target), "IX_email"));
+    }
+
+    // Target only: the snapshot is history, and a model that fixes the collision must diff.
+    [TestMethod(DisplayName = "SQLite: a cross-table collision in the source model does not block the fix")]
+    public void Sqlite_collision_in_source_stays_diffable()
+    {
+        var operations = MigrationHarness.CoreDiff(
+            MigrationHarness.SqliteModel<ComplexOnTwoTablesContext>(),
+            MigrationHarness.SqliteModel<ComplexOnTwoTablesFixedContext>());
 
-        Assert.HasCount(2, creates);
-        CollectionAssert.AreEquivalent(new[] { "companies", "people" }, creates.Select(o => o.Table).ToList());
+        CollectionAssert.AreEqual(new[] { "companies" }, CreatedTables(operations, "IX_company_name"));
     }
 
     [TestMethod(DisplayName = "An index moving from native to complex under one name still diffs")]
@@ -143,4 +307,49 @@ public void Handover_from_native_to_complex_still_diffs()
         Assert.IsTrue(operations.OfType<DropIndexOperation>().Any(o => o.Name == "IX_people_name"));
         Assert.IsTrue(operations.OfType<CreateIndexOperation>().Any(o => o.Name == "IX_people_name"));
     }
+
+    // ── SQL Server: one namespace per table ──
+
+    [TestMethod(DisplayName = "SQL Server: two complex indexes may share a name across tables")]
+    public void Sql_server_allows_complex_name_on_another_table()
+    {
+        var target = MigrationHarness.SqlServerModel<ComplexOnTwoTablesContext>();
+
+        CollectionAssert.AreEquivalent(
+            new[] { "companies", "people" },
+            CreatedTables(MigrationHarness.SqlServerDiff(null, target), "IX_name"));
+    }
+
+    [TestMethod(DisplayName = "SQL Server: a complex index may share a native index's name on another table")]
+    public void Sql_server_allows_native_name_on_another_table()
+    {
+        var target = MigrationHarness.SqlServerModel<NativeOnAnotherTableContext>();
+
+        CollectionAssert.AreEquivalent(
+            new[] { "companies", "people" },
+            CreatedTables(MigrationHarness.SqlServerDiff(null, target), "IX_name"));
+    }
+
+    // ── PostgreSQL: one namespace per schema ──
+
+    [TestMethod(DisplayName = "PostgreSQL: a complex index named like a native index on another table is rejected")]
+    public void Npgsql_rejects_native_name_on_another_table()
+    {
+        var target = MigrationHarness.NpgsqlModel<NativeOnAnotherTableContext>();
+
+        var exception = Assert.ThrowsExactly<InvalidOperationException>(() => MigrationHarness.NpgsqlDiff(null, target));
+
+        StringAssert.Contains(exception.Message, "HasIndex on table 'companies'");
+        StringAssert.Contains(exception.Message, "unique per schema");
+    }
+
+    [TestMethod(DisplayName = "PostgreSQL: two complex indexes may share a name across schemas")]
+    public void Npgsql_allows_complex_name_in_another_schema()
+    {
+        var target = MigrationHarness.NpgsqlModel<ComplexInTwoSchemasContext>();
+
+        CollectionAssert.AreEquivalent(
+            new[] { "companies", "people" },
+            CreatedTables(MigrationHarness.NpgsqlDiff(null, target), "IX_name"));
+    }
 }
diff --git a/test/EFCore.ComplexIndexes.Tests/NpgsqlNameCollisionTests.cs b/test/EFCore.ComplexIndexes.Tests/NpgsqlNameCollisionTests.cs
index fcc9d37..b84e05c 100644
--- a/test/EFCore.ComplexIndexes.Tests/NpgsqlNameCollisionTests.cs
+++ b/test/EFCore.ComplexIndexes.Tests/NpgsqlNameCollisionTests.cs
@@ -139,6 +139,23 @@ protected override void Configure(ModelBuilder m)
         }
     }
 
+    private class ComplexIndexesInDefaultAndPublicSchemaContext(DbContextOptions<ComplexIndexesInDefaultAndPublicSchemaContext> o) : ModelContext(o)
+    {
+        protected override void Configure(ModelBuilder m)
+        {
+            m.Entity<Booking>(b =>
+            {
+                MapBooking(b);
+                b.HasComplexIndex(x => x.Code, indexName: "ix_by_code");
+            });
+            m.Entity<Stay>(b =>
+            {
+                MapStay(b, "public");
+                b.HasComplexIndex(x => x.Code, indexName: "ix_by_code");
+            });
+        }
+    }
+
     private class TemporalForeignKeyLikeNativeForeignKeyContext(DbContextOptions<TemporalForeignKeyLikeNativeForeignKeyContext> o) : ModelContext(o)
     {
         protected override void Configure(ModelBuilder m)
@@ -284,14 +301,24 @@ public void Temporal_constraint_like_native_index_elsewhere_collides()
     public void Temporal_constraint_like_complex_index_collides()
         => StringAssert.Contains(Rejected<TemporalLikeComplexIndexContext>().Message, "(42P07)");
 
+    // Reported by the core's own check, under the PostgreSQL satellite's IndexNameScope.Schema.
     [TestMethod(DisplayName = "Two complex indexes with one name on different tables of one schema are rejected")]
     public void Complex_indexes_across_tables_collide()
     {
         var message = Rejected<ComplexIndexesAcrossTablesContext>().Message;
-        StringAssert.Contains(message, "complex index 'ix_by_code'");
+        StringAssert.Contains(message, "both resolve to the name 'ix_by_code'");
         StringAssert.Contains(message, "unique per schema");
     }
 
+    // The core compares schemas as configured; only this check knows an unset one means 'public'.
+    [TestMethod(DisplayName = "A complex index in the default schema collides with one in an explicit 'public' schema")]
+    public void Complex_indexes_in_default_and_explicit_public_schema_collide()
+    {
+        var message = Rejected<ComplexIndexesInDefaultAndPublicSchemaContext>().Message;
+        StringAssert.Contains(message, "complex index 'ix_by_code'");
+        StringAssert.Contains(message, "unique per schema ('public')");
+    }
+
     [TestMethod(DisplayName = "A temporal foreign key named like a native foreign key on its table is rejected")]
     public void Temporal_foreign_key_like_native_foreign_key_collides()
         => StringAssert.Contains(Rejected<TemporalForeignKeyLikeNativeForeignKeyContext>().Message, "the foreign key on table 'stays'");