Well, I can tell the difference between MediaInfo implementations in Shareaza, GreyLink and FlyLink. Shareaza has pretty full metainformation gathered in a single file. This allows browsing filelist as either folder hierarchy or medialibrary grouped by artist and album; season and episode and so on. GreyLink doesn't build such file, but it is possible to send a query for a single file. FlyLink includes metainformation into filelist, but this metainformation only tells about audio and video quality. E. g. no artist name. I can tell which clients support .dcls metafiles (sublists) in which way. Historically, the first evidence was IceDC++ that has sublists named ".DcLst". GreyLink (being the most advanced in many ways) names sublists as ".dcls". It looks like independent implementation, so .dcls was chosen independently. GreyLink supports recursive sublists. Recursive sublist has a metafile virtually put in the directory it describes. This is not important when someone uploads a metafile to a website, because metafile remains available on a website. However, it makes big sense when metafile and the directory it describes are being spread via magnet link to metafile. Availability of the small metafile becomes vital to downloading the virtual directory it describes. Finally, FlyLink developers were forced to implement dcls because users demanded. However, in order to be distinguished (they knew for sure that GreyLink uses .dcls) or maybe they have a wisdom overflow (не знаю, как по–английски «от большого ума»), either way FlyLink uses .DcLst.
I can tell for another features of modern DC++ clones. But the ones listed in this question are often I've never heard of, and I've never seen non-ADC-compatible DC++ clone. .PDC++? What is this? Never heard of. iDC++? What's the hell is this? Never heard of. Why are we talking about ADC support in 2011? It's a checkpoint that was passed long ago.