在 arch 标识符这种地方使用 loongarch 的主要坏处是——长。
以 Gentoo 为例：
Gentoo 的 eshowkw 工具，keywords 是纵列渲染的：
packages.gentoo.org 的 keywords 表格，横向空间很宝贵：
GLEP 53 明确提到：
Note that no limit on the length of both fields in the keyword are imposed. However, we cannot overemphasize our preference to keep keywords small and sensible.
“keyword 两个字段的长度没有限制。尽管如此，我们保持 keywords 短而靠谱的倾向性再怎么强调也不过分。”
因为我们一般称呼放置 Gentoo keyword 的配置项叫 ARCH，已经有 arch 四个字母了，那么叫 loongarch 就很冗长。事实上，最早的 Gentoo port 确实使用了 ARCH=loongarch，是上游讨论下来要改 loong 的。当时的讨论串在这里（从 In-Reply-To 字段可以链接到先前的邮件，一小串讨论）。
Go 项目采用 GOARCH=loong64 而非 GOARCH=loongarch64，也是相同原因。在 Go 上游的 porting issue 提出伊始，就有 Go 官方维护者指出：
I think "loong64" is good; a GOARCH value that itself contains the substring "arch" is redundant, we don't do that for any other.
“我觉得‘loong64’不错；一个自己就包含‘arch’子串的 GOARCH 取值显得冗余，我们在别的架构从未这么做。”
因此，出于尊重上游项目既有规范、秩序的考虑，对于那些有需求使用较短的架构标识符的场合，使用 loong、loong64 是比较好的选择。
（肯定有人会提议 la64。绝大多数地方不使用 la64 是因为我们这些认识 ia64 的老家伙还没入土。某种程度上这也是尊重不同群体。）
