dig +short for MX when the record is broken gives confusing answer

A confused user said that dig +short for an MX record did not report the preference level. The example he gave was:

# dig +short cyclonit.com MX
HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.

When given without +short, the reason becomes clear:

# dig cyclonit.com MX

; <<>> DiG 9.16.10 <<>> cyclonit.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65526
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b0e8599a68ce3729dc85d51e6003a03d038d9864e7c2e63c (good)
;; QUESTION SECTION:
;cyclonit.com.			IN	MX

;; ANSWER SECTION:
cyclonit.com.		10544	IN	CNAME	HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.

;; AUTHORITY SECTION:
elb.us-east-1.amazonaws.com. 53	IN	SOA	ns-1826.awsdns-36.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60

Yep, it's the dreaded "CNAME and MX at the same level" issue. However, +short hides that in a confusing way.

Proposal: dig +short for broken names such as this should instead reply "CNAME target", or possibly "Bad CNAME target".