Nick Sutterer's wroclove.rb 2022 talk retrospectively examining the Reform gem's design problems and presenting Reform 3. Opens with the story of how Reform was born in an Australian publishing company as a reaction to Rails' accepts_nested_attributes_for, which didn't scale beyond 'one form per model' and forced ifs/elses into models. Reviews Reform 2's DSL (property/collection, nested forms, validations, inheritable create/update forms) and runtime API (wrap a model, validate params, call save, use populators to parse nested hashes into object graphs). Identifies the central design mistake: a single mutable form instance that is used for rendering, validation and persistence, which users called validate/save multiple times, overrode setters with context-specific ifs, and misused populators as a general-purpose parsing hook. Reform 3 keeps the DSL but replaces the runtime API with class methods returning immutable objects: Reform.present(Form, model) returns a presentable form, Reform.validate returns a result object (a new one each call), persist returns a mutations object. Internally, Reform 3 is rebuilt on Trailblazer activities so parsing/validation/persistence are steps in a traceable flow; the Trailblazer tracer shows the exact execution path and exceptions even across five-level-nested forms. Reform 3 makes strong_parameters obsolete, works with dry-validation or Active Record validations, can coexist with Reform 2 in one app, and integrates with ROM (change sets) instead of Active Record. Sutterer also suggests Reform could back Avo's form engine. Q&A covers whether parsing and validation form a cycle (coercion as validation, solved by small inline dry-validation rules), whether the stack trace hints at monads (Trailblazer has its own success/failure railway dialect with tracing that monads lack), and what he'd do differently (maybe not Ruby; otherwise happy with the Trailblazer choice).