Your pasting-in of the code snippet lost all spaces. Some of them don't matter, but the one between assoc and 1 is necessary.
But anyway, those Mtexts somehow do the underlining in a different way than currently, without the { } "wrapper" around formatted parts. A sample instance returns:
"\\L+39.600"
So those don't meet the filter criteria for the content, which is why UUMT's object selection didn't "see" them. But sure enough, when edited to remove the +, it automatically gets "updated" to the current practice:
"{\\L39.600}"
Even simply double-clicking on one to get into Mtext-editing, and then clicking away to get out of it, without changing anything, causes the same update of the formatting code, so it's not about the + per se.
Maybe that no-{} way comes from an older version, or something brought in from other software, or....
But that "option" in the way the underlining is coded can be accounted for [minimally tested]:
(defun C:UUMT (/ ss n edata txt); = Un-Underline MText(s)
;; to remove underlining from Mtext whose ENTIRE content is underlined
(if (setq ss (ssget "_:L" '((0 . "MTEXT") (1 . "{\\L*,\\L*"))))
(repeat (setq n (sslength ss)); then
(setq
edata (entget (ssname ss (setq n (1- n))))
txt (cdr (assoc 1 edata))
); setq
(entmod
(subst
(cons 1
(if (= (substr txt 1 1) "{")
(substr txt 4 (- (strlen txt) 4))
(substr txt 3)
); if
); cons
(assoc 1 edata)
edata
); subst
); entmod
); repeat
); if
(princ)
)
Kent Cooper, AIA