What a DualSense found in the platformer template

Played with a DualSense: its input reaches the game (sticks, buttons, triggers). Dashing threw: the spawned player's dash curves had no keys list. Instantiate deep-copied [Serializable] classes without their constructors, so the engine's own (AnimationCurve, Gradient) lost state they keep outside serialized fields. Curves and gradients now copy their keys; other engine classes are made by their constructors first (scripts' classes as before).
The curves were empty before cloning too: a script field initialized in code (public AnimationCurve dashCurve = new AnimationCurve();) was filled in place field by field, which suits scripts' classes but not curves (Unity's YAML names aren't their fields). Curves and gradients are now read whole; Gradient fields are read at all (Unity's packed key0..7 / ctime / atime form, shared with particles).
Curves' m_PreInfinity and m_PostInfinity use Unity's own numbering (0 ping-pong, 1 loop, 2 clamp), not WrapMode's: every loaded curve had read as looping.
Script AnimationCurve and Gradient fields survive the editor's scene form and saving back to .unity (SerializedFields, UnitySnapshot, UnitySceneWriter).
The last pad used is current (Gamepad.current and the like), as in Unity, so a phantom pad Windows still lists can't take over; gilrs lives as long as the process (dropping it in a thread-local destructor at exit joined its thread and aborted); the player log has exceptions' stacks, as Unity's player log does.
Checked by instantiate_engine_values (new) and unity_import (an ImportProbe with initialized curve and gradient fields, loaded, overridden in the scene and instantiated), recorded in Unity 6000.3 (exact, and through the round trip).
Next: the template's QuadTextureMatPropBlock shader (the dash's after-images) doesn't compile; rumble; URP render features; humanoid avatars.
Then a stall: when a pass's last draw used a project's own shader, its bindings stayed for what the pass drew next, and particles failed wgpu's validation; the render thread panicked and the window froze while the game ran on. The pass returns to Tassix's own bindings after its last custom draw too (test particles_draw_after_a_custom_material_drawn_last), and the player quits with an error when its render thread stops, instead of showing a frozen window.