First, thanks for listing your pluses and minuses, you did a great job in laying out the differences and spelled out some of the reasons I think ASON would be a good fit.

I would like to mention that if DUB were to use the nameless field feature at all, I would only recommend it be supported in the "name" field on some of the objects (like dependency/subPackage). If people thought that even that was too confusing, I would recommend dismissing the feature all together.

My question is: can we parse any ASON file without application-dependent knowledge? I we can't then it's a show-stopper for any general parser.

Well a general purpose parser can accept a schema or provide some way for the application to tell it what types it is expecting. So I think your real question was, is there a way to convert any ASON to JSON without any application dependent knowledge. I believe that as long as there are no nameless fields, the answer is yes. I'll explain by using Nick's previous example. 

a b c

If this appeared in the beginning of the file, then this would be an object with it's curly-braces omitted. If it appeared within an explicit curly-brace section, it would represent: 

{            // SDL Version 
//...
a b c        // syntax error, field 'c' missing it's value
//...
}        
{            // JSON Version
//...
"a":"b","c"  // syntax error, field 'c' missing it's value
//...
}

Keep in mind even though this is valid ASON, if an object's fields are written this close together, I would use delimiters to make it easier to read: 

{a:b,c}        // SDL Version

If it was within a square-bracket section, it would represent: 

[a b c]
["a","b","c"]

Nick's other interpretations of the sequence a b c: 

"a":{"b":"c"}
"a":{"b":["c","d"]}
...

wouldn't be valid because every object needs curly-braces and every list needs square-brackets. However, if you have a bunch of crazy nameless fields you could get yourself into trouble, but that's why you only use them when it makes sense. In the case of DUB package files, allowing only one nameless field would require an ASON to JSON converter to have application knowledge, but the DUB parser itself would still be just fine.

Note: the reason ASON supports nameless fields is so that if other applications want to use them they have the option. There are some cases where nameless fields would be very useful, but for build configuration files this feature isn't that important.