Vagrant trigger desktop alerts after upgrading from 1.x to 2.2

Yes — on Vagrant 2.2 or later, attach the desktop alert to config.trigger.after :provision inside a Vagrant.configure("2") block. That hook means "provisioning finished," whereas after :up is broader and also fires for plain vagrant up runs that provisioned nothing or were no-ops. This assumes a version "2" Vagrantfile on Vagrant ≥ 2.2; Vagrant 1.x does not implement triggers at all, so there the block is silently ignored and no alert is sent.

Established behavior vs. likely explanation

Established: Vagrant 2.2+ honors config.trigger.before/after blocks; Vagrant provides no native notification channel, severity level, deduplication, or rate limiting; trigger stdout/stderr only appears in Vagrant's own output. The likely explanation for the duplicate alerts after upgrading is that each separate vagrant up, reload, or provision process re-runs the trigger and the host notifier emits again — there is no dedup layer in between.

Minimal host-side alert

Use the trigger's host-side run step (not run_remote, which executes inside the guest) with your OS notifier:

Vagrant.configure("2") do |config|
  config.trigger.after :provision do |trigger|
    trigger.info = "Provisioning finished"
    trigger.run = { inline: "notify-send 'Vagrant' 'Provisioning finished'" } # Linux
    # macOS: osascript -e 'display notification \"Provisioning finished\" with title \"Vagrant\"'
    # Windows: a PowerShell notifier module or msg equivalent
  end
end

Your three questions

1. after :provision vs :up — use after :provision when the alert must mean "provisioning finished." after :up fires even when no provisioning ran.
2. Suppressing duplicates without external state — not reliably. An in-memory guard dies with the Vagrant process, and every CLI invocation is a new process. If your notifier supports a stable replacement or group ID, reuse it so the alert replaces itself; otherwise a small state file or lock in the host temp directory is the practical option, or you accept duplicates. Vagrant itself will not dedupe.
3. Provider ordering — yes, boot and shared-folder mount ordering is provider-specific, and trigger timing relative to those steps is not strictly guaranteed. Treat the host alert as best-effort; for critical steps, gate on the provisioner's exit status and logs, and put the final notice in the last provisioner or a machine-side status check rather than relying on the trigger alone.

Verify on your exact versions

Vagrant 2.2 is old and trigger/provider behavior is version-sensitive, so confirm on your actual release before relying on it:

• Run vagrant --version and note your provider plugin version (VirtualBox, VMware, etc.).
• Run vagrant validate, then use a minimal Vagrantfile whose after :provision trigger echoes a marker; run vagrant up --provision, vagrant provision, plain vagrant up, and vagrant reload --provision, recording which commands emit the marker.
• Make a provisioner fail intentionally and check whether after :provision still runs, and whether a non-zero trigger exit status fails the whole command on your version. Only after that result, wrap the notifier so a notification failure cannot break provisioning.
• Run vagrant provision twice and compare a notifier replacement ID against a state-file guard; check your notifier's own documentation for replace/group semantics before relying on them.

Cautions

• Do not treat the desktop alert as an audit trail — repeated runs can duplicate, reorder, or drop notifications.
• Keep secrets out of trigger commands and inline scripts, because Vagrant may display trigger stdout/stderr.
• If the same project must still boot under Vagrant 1.x, keep the trigger block isolated — 1.x ignores it and sends nothing.

One diagnostic detail would pin down the exact recommendation: your host OS and notifier, plus the exact vagrant --version and provider versions, since those determine the notifier command and the trigger exit-status behavior.