Roundtripping failure with `pp.analyze` and coercions

Prerequisites

Please put an X between the brackets as you perform the following steps:

• Check that your issue is not already filed:
  https://github.com/leanprover/lean4/issues
• Reduce the issue to a minimal, self-contained, reproducible test case.
  Avoid dependencies to Mathlib or Batteries.
• Test your test case against the latest nightly release, for example on
  https://live.lean-lang.org/#project=lean-nightly
  (You can also use the settings there to switch to “Lean nightly”)

Description

The term 0 ≤ (↑n : Int) delaborates as 0 ≤ ↑n (with pp.analyze). This then re-elaborates as 0 ≤ n, so the coercion is lost:

import Lean

open Lean Lean.Meta Lean.Elab.Term Lean.PrettyPrinter in
#eval show TermElabM Unit from do
  withLocalDeclD `n (.const ``Nat []) λ _ => do
    let type ← elabTerm (← `(0 ≤ (↑$(mkIdent `n) : Int))) none
    synthesizeSyntheticMVarsNoPostponing
    let delabed ← withOptions (pp.analyze.set · true) $ delab type
    logInfo m!"delaborated: {delabed}"
    let type' ← elabTerm delabed none
    synthesizeSyntheticMVarsNoPostponing
    logInfo m!"re-elaborated: {type'}"
    logInfo m!"defeq: {← isDefEq type type'}"

/-
delaborated: 0 ≤ ↑n

re-elaborated: 0 ≤ n

defeq: false
-/

Context

I use the delaborator in aesop? to generate tactic scripts. Due to this issue, some of these tactic scripts don't elaborate correctly.

Brief Zulip discussion.

Versions

"4.9.0-nightly-2024-05-31"

Impact

Add 👍 to issues you consider important. If others are impacted by this issue, please ask them to add 👍 to it.

Start with the reproducible TermElabM snippet using pp.analyze, delab, and elabTerm, then inspect the pretty-printer and elaborator paths involved in coercions. Done means the delaborated 0 ≤ ↑n re-elaborates with the coercion preserved and the final defeq is true.