I’m trying to pick a quantum programming language and bumped into a question I haven’t seen discussed much: should quantum languages make noise, calibration, and error mitigation first-class features instead of leaving them as backend-specific configs or separate tool calls?

Right now, a lot of tutorials bolt mitigation and calibration on after the fact (provider APIs, separate libraries, custom scripts). That makes my code feel non-portable and hard to reproduce later. As a beginner, I’d love to express “how to run” alongside “what to run” in a way that survives compilation and provider changes.

Curious what folks think about these ideas:

First-class “execution context” in the language. Something like: run this subroutine “as is” under a specified noise model or with a particular mitigation policy (e.g., ZNE, M3, PEC), and make it part of the program semantics rather than a backend flag. Has any language done this cleanly?
Reproducibility baked in. Can the language/IR carry enough provenance (noise model version, calibration snapshot ID, mitigation recipe, random seeds, shot allocation) so that six months later I can replay the exact same experiment on a different stack?
Static checks for common pitfalls. Things like “you used a qubit after measurement without reset,” “control flow assumes mid-circuit measurement not supported on target,” or “your code implicitly assumes full connectivity.” Which languages catch these issues at compile time vs at runtime, if at all?
Intent-preserving IR. Is there an IR that actually keeps these higher-level intents intact end-to-end (OpenQASM 3 with pragmas? QIR with metadata?), so providers can either honor them or respond with a capability error instead of silently dropping them?
Optimization awareness. If I annotate that a block must be executed under a certain mitigation strategy or timing constraint, how should compilers treat that? Do they need a “don’t fuse across this boundary” or “keep measurement ordering” guarantee? Any prior art?
Variational workflows. Could things like shot-frugal batching, observable grouping, and estimator strategies be expressed in the language (not just libraries) so VQE/QAOA code behaves consistently across simulators and hardware?
Minimal viable syntax. If you could sketch a tiny language feature to cover 80% of real workflows, what would it look like? For example, something like: with mitigation=“zne”, calibration=“snapshot:1234”, shots=20k: run ansatz on H2.

If you’ve tried to standardize this in a real project, how did you structure it? Are there emerging patterns in Qiskit, Cirq, Q#, Braket, PennyLane, or tket that I should look at? Pointers to prototypes or papers would be super helpful.

Also interested in the trade-offs: does putting this in the language harm portability, or does it actually improve it by making constraints explicit?