This is a bit unfortunate, because we decided to always prefix subpaths with ./: https://github.com/NixOS/nixpkgs/tree/master/lib/path#leading-dots-for-relative-paths

This is the only reason why subpaths are not valid as components.

Anyways, it's already too late now, and it's not like a big problem, just a bit unfortunate 🙃

I don't even think it's unfortunate. Those are clearly components, not subpaths. No ambiguity there, no inconsistency.

Oh this has a mistake in it. The resulting strings are valid subpaths, they're just not normalised.

Edit: Now reworded

Here subpath should also be a link to a definition, but I'll merge this so you can do it in the other PR where I said the same.

(for reference: #244358 (comment))

Let's conclude that thread first before merging here.

I now added a link to subpath.isValid, which after the above PR is merged will contain a definition for it. This PR is not dependent on that PR however.

Here's why this was added: #244358 (comment)

I wish we didn't repeat Haskell's mistake. At your discretion.

All of lib.lists uses [ ] so let's stick with that for now. Am wondering what the problem with [ ] in Haskell is though (I only know Idris doesn't support [ ])

That's right, it's a problem with dependent types, which hints at the more general problem that the list type is not a list.
In Nix we can exemplify this by asking the question what is [ Attrs String ]?
a. A type for lists of any number of elements, each of which is an attrset with string values only,
b1. A type for two-element heterogeneous lists where the first is an attrset and the second is a string,
b2. A type for one-element lists where the element is an attrset with string values only.

That just looks like ambiguous notation to me, same as if you wrote List Attrs String. Needs parenthesis to make sense

I guess the b1/b2 distinction was a distraction. a/b2 is the one that's the problem: the list type is not a list, so it shouldn't use the notation of the list literal.

Ah I get it now, if both list values and types use the same syntax it's ambiguous and confusing. [ x ] could either be a single-value list with the element x, or if x is a type the type of a list of x's. In comparison [ x y ] can only be one.

So using List x for the type and [ ... ] for values disambiguates them better