Removed the speculatively-added UNICODE_CODEPOINT collation.

Author: RyanLamansky

SqlServerSimulator.Tests/CollationDeclaredColumnTests.cs

@@ -332,7 +332,6 @@ public void InList_CrossCollation_RaisesMsg468()
     [DataRow("Turkish_CI_AS")]
     [DataRow("Latin1_General_CI_AS_KS_WS")]
     [DataRow("SQL_Latin1_General_CP437_CS_AS")]
-    [DataRow("UNICODE_CODEPOINT")]
     public void NewCollation_AcceptedAndRoundTripsThroughSysColumns(string collationName)
     {
         var sim = new Simulation();
@@ -453,7 +452,6 @@ insert t values (N'Hello')
     [DataRow("Latin1_General_BIN2")]
     [DataRow("Latin1_General_CI_AS_KS_WS")]
     [DataRow("SQL_Latin1_General_CP437_CS_AS")]
-    [DataRow("UNICODE_CODEPOINT")]
     [DataRow("Japanese_XJIS_140_CI_AS")]
     [DataRow("Chinese_PRC_CI_AS")]
     [DataRow("Turkish_CI_AS")]
@@ -485,7 +483,6 @@ insert t values (N'banana'), (N'apple'), (N'cherry')
     [DataRow("Latin1_General_BIN2", 3)]
     [DataRow("Latin1_General_CI_AS_KS_WS", 1)]
     [DataRow("SQL_Latin1_General_CP437_CS_AS", 3)]
-    [DataRow("UNICODE_CODEPOINT", 3)]
     [DataRow("Japanese_XJIS_140_CI_AS", 1)]
     [DataRow("Chinese_PRC_CI_AS", 1)]
     [DataRow("Turkish_CI_AS", 1)]

SqlServerSimulator.Tests/CollationMetadataTests.cs

@@ -125,7 +125,7 @@ public void Column_Collate_UnrecognizedName_RaisesNotSupported()
 
     [TestMethod]
     public void FnHelpCollations_ListsRecognized()
-        => AreEqual(27, new Simulation().ExecuteScalar(
+        => AreEqual(26, new Simulation().ExecuteScalar(
             "SELECT COUNT(*) FROM sys.fn_helpcollations()"));
 
     [TestMethod]

SqlServerSimulator/Collation.cs

@@ -200,22 +200,6 @@ private protected Collation()
     /// </summary>
     internal static readonly CultureCollation SqlLatin1GeneralCp437CsAs = new("SQL_Latin1_General_CP437_CS_AS", CultureInfo.InvariantCulture.Name, caseSensitive: true);
 
-    /// <summary>
-    /// "UNICODE_CODEPOINT" — pure ordinal Unicode codepoint comparison.
-    /// Semantically equivalent to <see cref="Latin1GeneralBin2"/> at the
-    /// value level; the name appears on a handful of system columns in
-    /// some BACPACs (notably AdventureWorks2025). Reuses the binary
-    /// codepath via a separate metadata-only instance.
-    /// </summary>
-    internal static readonly UNICODE_CODEPOINT UnicodeCodepoint = new();
-
-    /// <summary>Metadata-only binary collation under the
-    /// <c>UNICODE_CODEPOINT</c> name; behavior body is <see cref="BinaryCollation"/>.</summary>
-    internal sealed class UNICODE_CODEPOINT : BinaryCollation
-    {
-        public override string Name => "UNICODE_CODEPOINT";
-    }
-
     /// <summary>"Korean_100_CI_AS" — Korean (Hangul) v100 sort via .NET's
     /// <c>ko-KR</c> <see cref="CompareInfo"/>. Same sort-tiebreaker
     /// divergence caveat as the other locale collations
@@ -341,7 +325,6 @@ internal sealed class Latin1_General_100_BIN2_UTF8 : BinaryCollation
             [Latin1GeneralBin2.Name] = "Latin1-General, binary code point comparison sort",
             [Latin1GeneralCiAsKsWs.Name] = "Latin1-General, case-insensitive, accent-sensitive, kanatype-sensitive, width-sensitive",
             [SqlLatin1GeneralCp437CsAs.Name] = "Latin1-General, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 30 on Code Page 437 for non-Unicode Data",
-            [UnicodeCodepoint.Name] = "Unicode code point comparison sort",
             [JapaneseXJIS140CiAs.Name] = "Japanese-XJIS-140, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive",
             [ChinesePrcCiAs.Name] = "Chinese-PRC, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive",
             [TurkishCiAs.Name] = "Turkish, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive",
@@ -379,7 +362,6 @@ internal sealed class Latin1_General_100_BIN2_UTF8 : BinaryCollation
             [Latin1GeneralBin2.Name] = Latin1GeneralBin2,
             [Latin1GeneralCiAsKsWs.Name] = Latin1GeneralCiAsKsWs,
             [SqlLatin1GeneralCp437CsAs.Name] = SqlLatin1GeneralCp437CsAs,
-            [UnicodeCodepoint.Name] = UnicodeCodepoint,
             [JapaneseXJIS140CiAs.Name] = JapaneseXJIS140CiAs,
             [ChinesePrcCiAs.Name] = ChinesePrcCiAs,
             [TurkishCiAs.Name] = TurkishCiAs,

docs/claude/collations.md

@@ -58,7 +58,7 @@ Chained `expr COLLATE A COLLATE B` rejects with Msg 156 at parse time (probe-con
 
 ## Recognized catalog
 
-27 entries today. Resolution at parse / load time consults the case-insensitive `Collation.ByName` map; names outside the set raise `NotSupportedException` in direct SQL and surface on `BacpacImportResult.Warnings` for BACPAC loads (graceful degradation).
+26 entries today. Resolution at parse / load time consults the case-insensitive `Collation.ByName` map; names outside the set raise `NotSupportedException` in direct SQL and surface on `BacpacImportResult.Warnings` for BACPAC loads (graceful degradation).
 
 ### Latin1 / SQL_Latin1
 
@@ -75,7 +75,6 @@ Chained `expr COLLATE A COLLATE B` rejects with Msg 156 at parse time (probe-con
 | `Latin1_General_100_CI_AS_SC_UTF8` | Invariant culture CI (same body as `_100_CI_AS`) | UTF-8 is a storage encoding only at the simulator's UTF-16 value layer; `_SC` (supplementary characters) is handled natively by `CompareInfo`. |
 | `Latin1_General_100_CS_AS_SC_UTF8` | Invariant culture CS | Same body as `Latin1_General_CS_AS`. |
 | `Latin1_General_100_BIN2_UTF8` | `StringComparer.Ordinal` (`BinaryCollation` body) | Pure codepoint binary; UTF-8 storage doesn't alter compare semantics. |
-| `UNICODE_CODEPOINT` | `StringComparer.Ordinal` (`BinaryCollation` body) | Semantically equivalent to BIN2 at the value level; appears in AdventureWorks2025. |
 
 ### CJK locales
 
@@ -124,7 +123,7 @@ The two bodies diverge for any string containing characters whose CP1252 byte li
 
 The dispatch hangs off `Collation.ForVarcharStorage()` (a virtual returning `this` by default; the BIN / BIN2 singletons override to point at the `Cp1252BinaryCollation` sibling). `VarcharSqlType.WithCollation` and `CharSqlType.WithCollation` call it at column-pin time; `NVarcharSqlType` / `NCharSqlType` don't substitute. Both bodies share the same `Name` so catalog views report one collation name and `Collation.Resolve` treats them as the same collation for cross-operand coercibility.
 
-`Latin1_General_100_BIN2_UTF8` keeps the codepoint-order body — UTF-8 byte order equals codepoint order (UTF-8 invariant), so the substitution isn't needed even though it's a varchar collation. `UNICODE_CODEPOINT` is Unicode-only (the simulator doesn't reject it on varchar at parse time — a low-priority gap).
+`Latin1_General_100_BIN2_UTF8` keeps the codepoint-order body — UTF-8 byte order equals codepoint order (UTF-8 invariant), so the substitution isn't needed even though it's a varchar collation.
 
 ### Microsoft-docs-vs-real-behavior gap: BIN2 is code *unit*, not code point
 
@@ -151,7 +150,6 @@ The pre-2005 `_BIN` (not `_BIN2`) variant has a different, real quirk: at positi
 - **Set ops (UNION / UNION ALL / INTERSECT / EXCEPT) don't apply collation-conflict checks at the column-pair level yet.** Probe showed UNION raises Msg 468, UNION ALL raises Msg 457 across cross-collation columns; the simulator's set-op type-promotion path doesn't call `Collation.Resolve`. Cross-collation set-op columns currently fall through to the legacy type-precedence resolution.
 - **`text` / `ntext` columns can't be declared with an explicit COLLATE in the simulator.** Real SQL Server allows it; the simulator's single-instance modeling collapses all text/ntext to the default. Low impact (text/ntext deprecated since SQL Server 2005).
 - **Sysname's collation is always `Collation.Default`** at `Implicit` rank — real SQL Server's sysname inherits the server's catalog collation which can differ from the user database's collation; the simulator's single-instance modeling collapses them.
-- **`UNICODE_CODEPOINT` is over-permitted.** Real SQL Server 2025 rejects `COLLATE UNICODE_CODEPOINT` with `Invalid collation 'UNICODE_CODEPOINT'.` — it's an internal-only collation that surfaces on XML-index storage columns in `sys.columns.collation_name` (probed against `AdventureWorks2025.sys.xml_index_nodes_*`) but isn't on `sys.fn_helpcollations()` and can't be applied in a `COLLATE` clause. The simulator accepts it everywhere via the same `Recognized` whitelist that drives BACPAC catalog round-trip. Splitting "loader-recognized" from "COLLATE-acceptable" requires a separate dispatch flag; deferred because real exposure is narrow (someone manually typing `COLLATE UNICODE_CODEPOINT` in user SQL).
 - **`Latin1_General_100_BIN2_UTF8` and the other `*_UTF8` collations are storage-misencoded.** Real SQL Server stores values as UTF-8 bytes (`€` U+20AC → 3 bytes `E2 82 AC`, `NBSP` U+00A0 → 2 bytes `C2 A0`, 😀 U+1F600 → 4 bytes `F0 9F 98 80`). The simulator collapses all varchar storage to CP1252 regardless of collation, so `DATALENGTH`, `LEN` (under `_SC_UTF8`), and storage-size budgeting diverge for non-ASCII inputs. Sort happens to match for most cases because UTF-8 byte order == UTF-16 codepoint order == `StringComparer.Ordinal` (the simulator's value layer). Fixing this requires per-collation storage encoder dispatch in `VarcharSqlType.Encode/Decode`; deferred as a significant refactor.
 - **`_SC_` (supplementary-character-aware) semantics aren't modeled.** Probe showed three observable effects on SQL Server 2025 the simulator doesn't replicate:
   - `LEN(N'😀')` returns 2 under non-`_SC_` collations, 1 under `_SC_`. The simulator always returns code-unit count (2 in this case).