diff --git a/meetings/2025/README.md b/meetings/2025/README.md
index 6d5f0d5f76..76a0a7034d 100644
--- a/meetings/2025/README.md
+++ b/meetings/2025/README.md
@@ -4,6 +4,8 @@ All schedule items must have a public issue or checked-in proposal that can be l
 
 ## Schedule ASAP
 
+- [Partial constructors open question](../../proposals/partial-events-and-constructors.md#break-in-top-level-contexts) (Jan)
+
 ## Schedule when convenient
 
 - Triage (working set)
diff --git a/proposals/partial-events-and-constructors.md b/proposals/partial-events-and-constructors.md
index becc3782d7..e3562d5f2d 100644
--- a/proposals/partial-events-and-constructors.md
+++ b/proposals/partial-events-and-constructors.md
@@ -243,6 +243,19 @@ We propose the first two member kinds, but any other subset could be considered.
 Partial *primary* constructors could be also considered,
 e.g., permitting the user to have the same parameter list on multiple partial type declarations.
 
+### Break in top-level contexts
+
+Constructors cannot be defined in top-level statements or scripts, i.e., the following is legal today:
+
+```cs
+System.Console.Write(F().GetType().Name); // prints "partial"
+partial F() => new();
+class @partial;
+```
+
+Do we want to keep this behavior or can we break here and simplify the parser?
+If we break, the workaround for users is to use `@partial` for the return type of the method as well.
+
 <!--------
 ## Links
 --------->