"dev, gn, /svc, /pkg, PA_VMAR_ROOT"
Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.
I don't have trouble understanding dev, /svc and /pkg because they're already common abbreviations. The gn and PA_VMAR_ROOT I'd have to look up, but if I'm using it constantly, I don't mind needing to learn. I mean, I needed to learn to use Vim, too, and now I'd never want anything else.
"Self-explanatory": That doesn't exist. You always need context. The art is to use just enough verbosity. Say the interesting and distinctive things. Not the boring things that can be easily figured out (Singleton, Factory, boring. What kind of component?)
And how long does it take you to parse "svc" vs. "service" in average microseconds per day? With old unix there was at least a need to keep memory use low, today we are only limited by Microsofts MAX_PATH.
/svc, which is a bundle of services from the environment in which the application runs.
Now, since this is a distinctive concept that comes with a learning cost, why not make a short name like "svc" for it? That is actually more distinctive than "service". And you save 4 characters every time you read or write it.
Also you rarely need to type full paths even on Linux. I'm nearly all shells you can press tab to autocomplete them. I.e. you press "/d<tab>" and it will change it to /dev. That's exactly the same for dev and devices.
There's really no reason for short confusing names other than laziness and jargon-based egotism.
People who don't understand need to know that big / Retina displays are not accessible to people who, let's say it, are poor immigrant geniuses who only have access to a 1024*768.
Terminals are 80x24, and even system administrators need to have multiple terminal windows open.
Let's not forget that a lot of people learn through books, so print real estate is an issue as well.
svc is especially cringy.