The problem with "skins" is that they create variety where people strive for uniformity to lower the cognitive load. OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that.
That's one of my hopes for the future of the industry: people will be able to just choose the code style and even syntax family (which you're calling skin) they prefer when editing code, and it will be saved in whatever is the "default" for the language (or even something like the Unison Language: store the AST directly which allows cool stuff like de-duplicating definitions and content-addressable code - an idea I first found out on the amazing talk by Joe Armstrong, "The mess we're in" [1]).
Rust, in particular, would perhaps benefit a lot given how a lot of people hate its syntax... but also Lua for people who just can't stand the Pascal-like syntax and really need their C-like braces to be happy.
Some languages have tools for more or less straightforward skinning.
Clojure to Tamil: https://github.com/echeran/clj-thamil/blob/master/src/clj_th...
C++ to distorted Russian: https://sizeof.livejournal.com/23169.html
One of my pet "not today but some day" project ideas. In my case, I wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts), one by one, via VSCode extension that implements a virtual filesystem over the real one which translates back & forth the syntaxes during the load/edit/save cycle. Then the whole live LSP background running for the underlying real source files and resurfacing that in the same extension with line-number matchings etc.
Anyone, please steal this idea and run with it, I'm too short on time for it for now =)
Neo makes it really easy to type those
The idea of "skins" is apparently to push that even further by abstracting the concrete syntax.
This has limits.
Files produced with tab=2 and others with tab=8, might have quite different result regarding nesting.
(pain is still on the menu)
More than that, in the general case for common C like languages things should almost never be nested more than a few levels deep. That's usually a sign of poorly designed and difficult to maintain code.
Lisps are a notable exception here, but due to limitations (arguably poor design) with how the most common editors handle lines that contain a mix of tabs and spaces you're pretty much forced to use only spaces when writing in that family of languages. If anything that language family serves as case in point - code written with an indentation width that isn't to one's preference becomes much more tedious to adapt due to alternating levels of alignment and indentation all being encoded as spaces (ie loss of information which automated tools could otherwise use).
Unfortunately the discussion tends to be somewhat complicated by the occasional (usually automated) code formatting convention that (imo mistakenly) attempts to change the level of indentation in scenarios where you might reasonably want to align an element with the preceding line. For example, IDEs for C like languages that will add an additional tab when splitting function arguments across multiple lines. Fortunately such cases are easily resolved but their mere existence lends itself to objections.
All that being said, I've very much a "as long as everyone working on the code does it the same, I'll be fine" sort of person. We use spaces for everything, with defined indent levels, where I am, and it works just fine.