DeviceLayout 2.0 — tracking issue

We don't have roadmap features forcing a breaking v2 anytime soon, but we have enough minor breaking changes we already know we want that it's worth getting a head start. The goal here is to track candidate changes and deprecations in one place to coordinate the next breaking release.

## Breaking change guidelines

**Opt-in first.** Whenever a change can be made available in a 1.x release behind a keyword or preference that defaults to current behavior, it should be. Then 2.0 is mostly a defaults flip, and users who opted in early see no change at all. Example: `Δθ`-vs-`rounded` ellipse path (1.6). Other new prospective default features like #295 can be introduced so that users who opt in early just need a find-and-replace.

**One loud transition release.** The last 1.x release before 2.0 is an upgrade-assist release (like Julia 0.7 → 1.0), removing nothing, with every 2.0 behavior reachable opt-in, and every planned removal carrying an actionable deprecation warning.

**What counts as breaking?**

- Changes to `ExamplePDK` are never breaking.
- Changes to curve discretization within the default or a specified tolerance are not breaking.
- Changing default mesh sizing is not breaking.
- Changing the return type of a public function (e.g. scalar → vector) is breaking even when the geometry is unchanged.
- Changing silently incorrect behavior to match documented behavior is not breaking.
- Changing underspecified behaviors to something more "correct" is breaking. For example, #8 describes undesirable `halo` outputs, but there's no well-specified contract under which some are clearly "wrong". Other boundaries between bugfixes and breaking changes may be more fuzzy, but lean towards opt-in fixes in v1 (e.g., rounding point selection tolerance) and call out fixed behavior as breaking in the v2 changelog.
- Changes to graphical output (color schemes, text display) are not breaking.

2.0 should be sure to formalize any additional subtle distinctions about what is and isn't breaking. (For example, we can make a decision about whether auto-generated unique names are meant to be stable, as raised in #198.)

## Release sequence

- **1.x prep minors** — additive APIs, opt-in flags, new deprecations (quiet, see below).
Bug fixes whose correct behavior differs from today land here behind flags where feasible.
- **1.LAST — upgrade-assist release.** No removals. Deprecation warnings become loud and actionable. Ships an "Upgrading to 2.0" doc page. Maybe ships a single preference that flips every opt-in default at once.
- **2.0.0** — flip defaults, remove deprecated API, land the changes that have no opt-in path (type/field changes, `getproperty` → `getindex`, graph restructuring).
- **1.LAST maintenance** — decide up front how long we backport fixes to the 1.x line and say so in the release notes.

## Deprecation warning policy

The current state is inconsistent:

- `Base.depwarn(...)` at most sites: invisible at default Julia settings, visible under `--depwarn=yes`, and repeated once per call with no `maxlog`.
- `src/solidmodels/render.jl` uses `Base.depwarn(..., force=true)` for `MeshingParameters`, which fires on every `render!` regardless of `--depwarn`.
- `src/polygons.jl` warns from the `Rounded` constructor, so a loop that builds styles warns per construction.
- `src/cells.jl` has `@deprecate layers(x) gdslayers(x)`, but `layers(x::Cell)` is still defined and is more specific so the warning never fires

Proposal:

- [ ] Use `Base.depwarn()` where a method is simply going away or being renamed
- [ ] Use default-visible warnings with `maxlog` where there is a new "more correct" usage to opt into
- [ ] Make all warnings loud and repeated in the upgrade-assist release
- [ ] Every message names the replacement spelling, not just the removal
- [ ] Test suite runs quiet, with one dedicated test item asserting each deprecation still warns
- [ ] Remove the `layers(::Cell)` shadowing so the existing deprecation actually applies.

## Candidate work items

Not all of these necessarily require a breaking release, and not all of them need to make it into 2.0.0.

### A. Canonical geometry and rendering core

- [ ] **#293.** `to_polygons`/`to_curvilinear` uniformly return a vector of disjoint regions; canonical representation needs one style-normalization pre-pass and seam handling before rounding/mesh sizing/backend rendering. Only the always-return-a-vector part is breaking; the flattening and normalization passes can land in 1.x.
- [ ] **#101.** Sequenced after #293, just constructor sugar on a canonical form.
- [ ] **#262.** Field type change; needs a decision on constructor aliasing semantics. Also fixes a latent eltype bug when rounding a B-spline-bearing polygon.
- [ ] **#264.** Walk PolyNode tree at all depths. Currently not used internally so blast radius is small.
- [ ] **#234.** 1.x: warn on wholly-CW input/tool collections. 2.0: normalize winding before clipping.
- [ ] **#244.** Two code paths mishandle mismatched compound segment/style grids. Bugfix changes rendered geometry, but current behavior is clearly wrong so the fix could land before 2.0.
- [ ] **#237.** uses the wrong normal when the base offset is non-constant. Bugfix changes rendered geometry, but current behavior is clearly wrong (and requires users messing with OffsetSegments, considered "internals") so the fix could land before 2.0.
- [ ] **#155** and **#231.** If the remedy for #231 is reordering rather than warning, it belongs here.
- [ ] **#247.** — remaining items 4/5 look non-breaking if we want to address them at any time.

### B. Paths, styles, routing

- [ ] **#8.** Four inconsistencies in `halo(::Path, ...)`, some need a spec decision rather than a fix.
- [ ] **#132.** Changes documented B-spline behavior; `auto_curvature` becomes stored state on the spline.
- [ ] **#265.** The fixed 2500 µm/t-unit default is scale-blind; the chord heuristic behaves well across scales. ~20 call sites; also decide whether `BSplineRouting` moves with it.
- [ ] **#21.** — deprecate the current meander functions, but we should also have a unified interface to replace them.
- [ ] **#149** in favor of channel-routed bundles. Trivial: it has never worked (rendering always errored), and varying the offset varies effective trace width, which is rarely what anyone wants.
- [ ] **#69** and **#12** — fix together or deprecate `CompoundRouteRule`.
- [ ] `GeneralOffset` has a mutable, untyped offset field; make it immutable and typed. More broadly: audit for unnecessarily mutable/untyped/abstractly-typed fields. *(No issue yet.)*
- [ ] `footprint` of an `Ellipse` should (maybe) be the `Ellipse`. Right now it falls back to `bounds`, which is a rectangle (and requires discretizing non-circles), and is inconsistent with converting to a polygon first. Similarly for `CurvilinearPolygon` and `CurvilinearRegion`. More broadly: `footprint` and `halo` contracts should be better-specified, with methods added or changed as appropriate. *(No issue yet.)*
- [ ] Non-finite `selection_tolerance` in `Rounded` is already deprecation-warned and becomes `1.0nm`; do the swap at 2.0.
- [ ] Default `global_waypoints=true`

### C. Schematics and graphs

- [ ] **#6.** `SchematicGraph` carries redundant state (`nodes` vector vs. vertex metadata) plus a `ComponentNode` wrapper, which blocks standard MetaGraph operations and serialization. Large, high-breakage; batch with #5.
- [ ] **#5.** Shares #6's refactor scope.
- [ ] Replace `getproperty` overloading for schematics, graphs, and composite components with `getindex`; stop mixing `Symbol` and `String` for node ids. *(No issue yet; related to #6.)*
- [ ] **#198.** One could argue that changing auto-generated names is not breaking, but I think that's something that needs to be established in advance.
- [ ] Store Component hooks in a dictionary like with CompositeComponents, where we can cache them and enforce coordinate type. Can't be done in the background in v1 (as we did for CompositeComponents) because designers implement the public `hooks` function directly. We can have designers opt in early by renaming their `hooks` method to `SchematicDrivenLayout._hooks` instead. *(No issue yet.)*

### D. Rendering options and keyword handling

- [ ] **#7.** `render!` forwards `kwargs...` through 5+ dispatch layers with no validation, so a misspelling is silently ignored. 1.x: warn on unrecognized options (allowlist). 2.0: an options struct, or error.
- [ ] **#275.** Same family as #7 but on a path an allowlist alone cannot fix, because acceptance is receiver-dependent. Needs the error-vs-drop decision made once, for both.
- [ ] **#287.** Component `_geometry!` exceptions escape raw on both the `Cell` and `SolidModel` paths; the documented `strict=:no` empty-geometry contract is only implemented in the optional `build!` step. Honoring it changes what escapes, but matching documented behavior is a bugfix. But also maybe we want partial geometry up to failure in one or both cases?
- [ ] **#4.** — typed `PostrenderOp` structs instead of tuples. Could be added in 1.x, and made required in 2.0.
- [ ] All methods that implicitly render should take rendering options (or maybe use a global context if we'd tolerate it). Could be 1.x, but cleaner/safer to sequence after #7. *(No issue yet.)*

### E. Identity, equality, transforms

- [ ] **#50.** Use `==` rather than `===` in the reference search.
- [ ] Enforce that a reference's coordinate type matches its coordinate system. Note the interaction: auto-conversion breaks reference lookup by `===`, so this and #50 must be decided together. *(No issue yet.)*

### F. SolidModel

- [ ] Physical groups of different dimensions should not be allowed to share a name, and `setindex!` with entities of several dimensions at once (which creates one group per dimension) should go away — it is not a useful convenience. (Do extrusions return entities of multiple dimensions?) *(No issue yet; `src/solidmodels/solidmodels.jl`.)*
- [ ] **#10** — additive, can land in 1.x, but relates to the naming policy above.

### G. Deprecation removals

All of these are in-tree today and simply need removing at 2.0:

- [ ] `SolidModels.MeshingParameters` (deprecated 1.8.0; the loud `force=true` site).
- [ ] `rounded` keyword in SolidModel rendering (deprecated 1.6.0; `Δθ` replaces it).
- [ ] `cliptree(op, s, c)` → `clip(op, s, c).tree` (deprecated 1.13.0).
- [ ] `circle` → `Circle` / `circle_polygon` (deprecated 1.6.0, #65).
- [ ] `layers` → `gdslayers` (and remove the shadowing `layers(::Cell)` method first).
- [ ] `filter_params` → `filter_parameters` in `ExamplePDK` — free, since `ExamplePDK`
changes are never breaking.

### H. Assorted speculation

- [ ] We may have a new system of entity metadata and SolidModelTargets incoming that could become the new default in 2.0.
- [ ] We may want to change module organization (why is `Ellipse` in `.Polygons`?) and reduce what's exported or public. But that's gratuitously breaking if we don't have a stronger justification than aesthetic preferences.

### Sequencing notes (not themselves breaking)

- **#199** aims to be output-faithful, but it rebaselines clip output ordering. A major boundary is a comfortable place for that to land.
- The change to warnings suggested but not implemented in **#298** is a prerequisite for the deprecation policy above: once warnings are one-shot and quiet-by-default, the transition release can turn them loud without drowning our own CI.

## Process

- Long-running `v2.0.0-dev` branch off `main`. Every breaking change is its own PR into `v2`, so it stays reviewable and revertible.
- Where an item has a v1 opt-in path, the opt-in PR targets `main` first; the `v2` PR then only flips the default.
- Integrate `main` into `v2` by **merge**, on a regular cadence, rather than rebasing. Rebase only while it is still solo.
- Changelog: keep a `## 2.0.0 (unreleased)` section on the `v2` branch with a `### Breaking` subsection. **Check it after every integration merge** — three-way merges follow context lines, not position, so changelog entries can silently land under the wrong version heading with no conflict.
- Attach everything above that we decide actually lands in 2.0.0 to [the `DeviceLayout 2.0.0` milestone](https://github.com/aws-cqc/DeviceLayout.jl/milestone/1) so the remaining scope is visible without reading this issue.

Start by reading the tracking issue and its candidate items, especially the referenced issues and the deprecation policy. Review the proposed v2.0.0-dev branch and release sequence; done means the breaking changes, opt-in paths, deprecations, sequencing, and upgrade-assist work are coordinated rather than implementing one isolated edit.

Written by the indexing model from the issue text.