From c26c169dbec7a99b0f85b2509d0d7331ea25d996 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ricardo=20Gro=C3=9F?= <ricardo@mr-gross.de>
Date: Tue, 22 Sep 2026 21:22:18 +0200
Subject: [PATCH 1/3] fix: check complex index names in the provider's
 namespace; open 5.4.1

Both core name checks grouped by table, schema and name, which is how
SQL Server scopes index names but not SQLite: SQLite keeps them unique
across the database and leaves configured schemas out of the DDL. Two
tables sharing an index name - two complex indexes, or a complex and a
native one - scaffolded cleanly and failed when applied ("index ...
already exists"), and IndexNameCollisionTests asserted that exact model
was fine.

IndexNameScope (Table, Schema, Database) is now a protected virtual on
the core differ, applied by ValidateUniqueIndexNames and
ValidateNoNativeIndexNameCollision. The core default is Database,
SQLite's rule and the widest scope, since the core also serves providers
without a satellite; SQL Server overrides to Table, PostgreSQL to
Schema. On PostgreSQL the core now reports plain index clashes first;
ValidateNamesAcrossKinds still covers keys, constraint-backed indexes
and an unset schema against an explicit 'public'. Only collisions with
one of this package's declarations are reported, in the target model
only.

Reverting the source fails 5 tests: the 3 SQLite rejections (no
exception thrown) and 2 PostgreSQL message assertions, which 5.4.0
answered from the cross-kind check. Dropping the SQL Server or
PostgreSQL override, or defaulting the core to Schema, each fails the
tests pinning it.

Version 5.4.1, package-validation baseline 5.4.0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 CHANGELOG.md                                  |   7 +
 CLAUDE.md                                     |  23 +-
 Directory.Build.props                         |   4 +-
 README.md                                     |  10 +-
 ...NpgsqlComplexIndexMigrationsModelDiffer.cs |  15 ++
 .../CHANGELOG.md                              |   6 +
 ...ServerComplexIndexMigrationsModelDiffer.cs |   6 +
 src/EFCore.ComplexIndexes/CHANGELOG.md        |  12 +
 .../CustomMigrationsModelDiffer.cs            |  79 ++++--
 src/EFCore.ComplexIndexes/IndexNameScope.cs   |  21 ++
 src/EFCore.ComplexIndexes/README.md           |   5 +-
 .../IndexNameCollisionTests.cs                | 233 +++++++++++++++++-
 .../NpgsqlNameCollisionTests.cs               |  29 ++-
 13 files changed, 408 insertions(+), 42 deletions(-)
 create mode 100644 src/EFCore.ComplexIndexes/IndexNameScope.cs

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..8740893 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -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/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'");

From ca06f4cd655f43cbb69d489b06265551d5bec657 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ricardo=20Gro=C3=9F?= <ricardo@mr-gross.de>
Date: Tue, 22 Sep 2026 21:30:43 +0200
Subject: [PATCH 2/3] docs: move the planned 5.4.0 features to 5.5.0 in the
 roadmap

5.4.0 shipped as a fix release: the 4.0 name registry went out, the
generic descriptor differ, the PostgreSQL delete constraint and the
small items riding along did not. The roadmap still scheduled them for
5.4.0. They move to 5.5.0 unchanged, D0 and step 0 are marked shipped,
and 4.0 notes the 5.4.1 index-name scope, which the generic differ's
name validation has to honour.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 CLAUDE.md  |  2 +-
 ROADMAP.md | 45 +++++++++++++++++++++++++++------------------
 2 files changed, 28 insertions(+), 19 deletions(-)

diff --git a/CLAUDE.md b/CLAUDE.md
index 8740893..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.
diff --git a/ROADMAP.md b/ROADMAP.md
index dad843c..82c3134 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,9 @@ 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 unchanged.
+
 ## 1. Where things stand
 
 **EF Core 11 makes the package name wrong.** `Microsoft.EntityFrameworkCore` 11.0.0-rc.1 was
@@ -55,8 +58,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 +75,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.
 
@@ -96,9 +100,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 +112,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 +124,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
@@ -176,7 +185,7 @@ 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.
+`[Obsolete]` in 5.5.0 and remove them in 6.0.0.
 
 ### 4.2 Delete constraints on PostgreSQL
 
@@ -246,7 +255,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,7 +293,7 @@ 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
@@ -336,7 +345,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`,
@@ -717,9 +726,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 +745,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; `[Obsolete]` constants | 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 | |

From 635ce57cd45d59221c13c132cde2d635bd155e19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ricardo=20Gro=C3=9F?= <ricardo@mr-gross.de>
Date: Tue, 22 Sep 2026 21:32:44 +0200
Subject: [PATCH 3/3] docs: correct the roadmap's EF constructor and
 temporal-constant claims

The sixth MigrationsModelDiffer constructor parameter (logger) is on
efcore main, which is 12.0.0 alpha; release/11.0 keeps five. EF Core 11
needs no #if around the differ constructor, so section 1, the D7 list of
build differences and the section 8 bullet now say so.

The temporal annotation constants 4.1 meant to mark [Obsolete] and
remove in 6.0.0 are internal, so there is no CP0002 break to schedule,
and not dead: NpgsqlComplexIndexSqlGenerator reads them to render
migrations scaffolded before 5.0.2. Removing them would let a fresh
database built from those migrations apply a plain UNIQUE or foreign
key without the period. The item is dropped from 4.1, 4.3 and the
sequence, and the 6.0 migration guide keeps the keys with the overrides
that read them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 ROADMAP.md | 38 +++++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/ROADMAP.md b/ROADMAP.md
index 82c3134..3822190 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -7,7 +7,9 @@ split them so the next five features do not each add a copy of the differ, and h
 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 unchanged.
+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
 
@@ -28,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
@@ -91,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
@@ -182,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.5.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
 
@@ -295,7 +299,6 @@ a `migration-safety-review` checklist item for row constraints.
 
 ### 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).
@@ -512,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
 
@@ -714,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.
@@ -746,7 +750,7 @@ the templates in 7.5 are in.
 | Step | Line | Content | Gate |
 |---|---|---|---|
 | 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; `[Obsolete]` constants | Suite green after each kind moves |
+| 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 |