Held Backspace is intermittently slow; acceleration differs by composing state #510

Describe the bug

On LeanType 4.2.2, holding Backspace sometimes deletes text quickly, but at other times deletion becomes noticeably slow or hesitant. This concerns ordinary press-and-hold deletion, not swiping on the delete key.

This is a user-observed symptom. Its exact cause has not been established by device traces. Source inspection found a reproducible inconsistency that may contribute: acceleration applies to committed text but not to an ordinary composing word.

To reproduce / expected behavior

There is no verified minimal reproduction of the intermittent phone symptom. Suggested diagnostic scenario: with suggestions enabled in a space-separated language, type several words including a long final word, then hold Backspace continuously through that word, a space and a previous word. Compare deletion across the composing/committed transitions without releasing the key.

Expected: a consistent acceleration policy during ordinary deletion, independent of whether a word is composing or resumed for suggestions. Selection deletion, autocorrection undo and whole gesture-word rejection should retain their special semantics.

These are proposed diagnostic steps, not a claim of reliable on-device reproduction. No recording, logcat or latency measurements are available. I am not planning additional device testing at present.

Source analysis / automated evidence

Audited release commit: 7e871955015d96a6ed6891ca186208d2ef4ab052. The relevant InputLogic.kt and WordComposer.kt files remain unchanged in inspected main 976a01e9d46fdcedbae9d479cbbfd6c746932229.

• DELETE_ACCELERATE_AT is 20.
• The ordinary composing branch applies one deletion, while the committed branch adds another above the threshold. Suggestion resumption can switch between these branches during the same hold.
• Three tests using the existing Robolectric input harness demonstrate the unequal deletion budget on unchanged release code: long composing word, resumed committed word, and crossing out of composition. They establish a deletion-count difference, not measured UI latency.

Other unmeasured candidates include synchronous InputConnection queries, counter resets after processing gaps above 200 ms, and synchronous session-word persistence. No evidence currently points to a swipe-library issue.

Previous experiment / related reports

Draft #503 is being withdrawn in favor of this issue. The branch, tests and analysis are preserved for reference; they are not a device-validated fix or a merge request to pursue at present. The PR records the experiment's review findings and corrections.

Related #439 and #463 request broader deletion gestures/behavior. This report is specifically about inconsistent speed during ordinary continuous holding.

App / device information

• Installed version: 4.2.2; installed flavor was not recorded.
• Automated tests used Standard Full; the input logic is shared.
• Model, Android version, affected editor and exact suggestion settings were not captured. No screenshot/device-specific claim is supplied.

Analysis and experimental tests were AI-assisted. Please assess the composing/committed inconsistency and whether it could explain the reported behavior; the symptom is not claimed to be fixed.