Track remaining legacy formatter paths and migration plan

[bhandras]

Context

After moving default logical-chain formatting off the old BreakAtOpAction logical path and onto the packed logical-chain formatter, there are still several formatter paths that are named or behaving as legacy compatibility code. This issue tracks which ones remain, which are active in the default next pipeline, and a proposed order for retiring or narrowing them.

Current default plan still reports:

dsl_multiline_style=packed-chain-layout
dsl_sigs_style=legacy
dsl_sigs_native=true
dsl_blank_lines_native=true
dsl_expr_logical_style=
dsl_expr_arithmetic_style=
dsl_expr_case_clause_style=
dsl_expr_selector_chain_style=
stage.blank-lines=dsl
stage.comments=dsl
stage.compact-calls=dsl
stage.expressions=dsl
stage.multiline-calls=dsl
stage.signatures=dsl

Active legacy or legacy-ish paths

Comment formatting

• formatter/dsl_bundles_next.go wires comments through dsl.LegacyCommentRules.
• The implementation delegates to internal/compat.FormatCommentsInSource / internal/compat/comment_formatter.go.
• This is still active by default.
• This is probably the least realistic piece to convert into normal AST DSL rules. It owns prose wrapping, directive preservation, raw-string/comment exclusion behavior, and comment-block semantics rather than expression layout.
• Recommendation: keep this as a specialized text/prose formatter for now, even if it remains wrapped as a DSL stage.

Signatures

• Default DSLSigsStyle is still "legacy".
• In default native mode this mostly means DSL signature rules using FormatFuncSignatureNext / FormatInterfaceMethodNext, not a first-pass whole-file legacy scanner.
• However, dsl.LegacyFuncSigFallbackRules(FormatFuncSigsInSource) is still appended as a final fallback.
• Recommendation: measure when the fallback fires, add targeted native DSL coverage for those cases, then remove or narrow the fallback.

Arithmetic chains

• DSLExprArithmeticStyle defaults to legacy behavior.
• LongExprRulesWithOptions still uses BreakAtOpAction for legacy arithmetic.
• There is already a conservative layout action for same-op arithmetic chains.
• Recommendation: consider making same-op arithmetic layout the default with BreakAtOpAction retained only as fallback for unsupported/mixed cases.

Case clauses

• DSLExprCaseClauseStyle defaults to legacy behavior.
• Legacy case formatting uses BreakCaseClauseAction.
• A layout action already exists: BreakCaseClauseLayoutAction.
• Recommendation: evaluate defaulting case clauses to layout, with golden/corpus verification.

Packed multiline calls

• Default multiline style is packed-chain-layout.
• Method chains use layout, but generic call arguments still commonly use packed multiline behavior via PackedMultiLineCallAction and FormatCallPackedMultiLineNextWithPrefix.
• This is not necessarily old scanner behavior, but the implementation and comments still preserve legacy packed output semantics.
• Recommendation: leave packed call output as a first-class style for now; only rename/document it clearly so it is not confused with deprecated legacy scanners.

Compatibility helpers that may be removable later

These appear to be compatibility APIs or historical bundles rather than default next pipeline paths:

• LegacyMultiLineCallRules
• LegacyMultiLineScanRules
• LegacyCompactCallRules
• LegacyBlankLinesRules
• expressionRules legacy-parity bundle, currently marked unused
• ExpressionRules / DefaultRules compatibility entry points, depending on whether the package is treated as public API

Proposed plan

1. Rename logical-chain "legacy" terminology internally/docs to "packed", keeping "legacy" accepted as a compatibility alias.
2. Audit signature fallback usage with trace/corpus tests. Convert high-value fallback cases into native DSL signature rules.
3. Switch case clauses to layout by default if corpus/golden output looks good.
4. Switch arithmetic to layout for safe same-op chains, preserving BreakAtOpAction fallback for mixed or unsupported expressions.
5. Remove unused historical rule bundles where they are not needed for tests or public API compatibility.
6. Leave comment formatting as a specialized text/prose formatter unless a separate comment-specific DSL is designed. It does not look like a good fit for ordinary AST expression/layout DSL rules.

Open question

Should we formally treat the exported dsl.Legacy*Rules helpers and older DefaultRules/ExpressionRules entry points as public API, or can they be deprecated and removed as part of next-only cleanup?