I feel that this seems like a good idea on paper, and a bad idea in the wild.
Last time I looked into shell syntax and such, I found out that most shells don't. They vary so greatly that very large context-free grammars have to be used to cover most of their context-sensitive rules. I don't think being POSIX compliant changes that.
I suspect that if this got popular usage, the bugs would be quite numerous.
In the deepest parts of my heart, I wish there was a programming language version of this.
It would make a good interview question to simulate reading a codebase in an unfamiliar language (without mixing the question to also test for problem-solving skills).
I feel like this question is poorly formed in the age of resume-driven development. I prefer types of problems to tackle. But, I don't have preferred stacks so much as stacks I dislike less that are prescribed for my consistent employment.
My least disliked stack is the one that doesn't make me obscure, keeps my future career progression options sub-/Pareto- optimally open, while still making my pay competitive. So in essence I align with whatever is the easiest to adopt and train others on with minimal supervision.
In my experience, pairing works really well to deal with ambiguity, as in problem solving.
In my experience, management often mistakes ambiguity with uncertainty when allocating resources to a project or engagement. This results in terrible pairing experiences where you've been allocated to a project where your normal tech. stack simply doesn't apply. You're suddenly in the weeds learning a new language / framework / deployment-environment playing catch-up with your pair, while your pair is trying to burn-down the actual task/story at hand.
Yes, Software engineers should be willing to learn new things. But, No, I'm not willing to sacrifice the primary psychological safety of knowing "I'm qualified to do my job" just to keep a cadence.
I crack open a book about the topic (usually from manning publishing). Self-document my learnings in the form of tree-structured bullet-point notes. Usually in a git book space.
I can always revisit the notes to quickly refresh myself on the topic (if a context-switch happens later down the line, or if the topic is not related to my day2day work).
I've successfully used this approach to onboard myself for a Spring project (known to have a steep learning curve). It was my second time using Spring, with an 8 month time separation. The ramp-up/refresh took about a week.
There were also some positive unintentional side-effects of my approach. I keep my gitbook notes public. I found that making my notes public ended up helping others on other teams in my company. Specifically, more experienced Spring devs who were new to Webflux were able to use my notes to jump right into a client's code base.
After scanning/browsing the first 2-3 pages, there's no point in looking any further. Might as well look at new.