The sample that you provided has a channel configuration (as defined in the AAC specification) of "7" and this corresponds to the channel layout "7.1 wide": FL FR C LFE BL BR FLC FRC (in a specific order but the order is not what this ticket is about afaict).
To the best of my knowledge, this is defined in the AAC specification and FFmpeg decodes the given sample in accordance with the specification (and its output matches QuickTime? output which may not be a strong argument, see below).
Afaiu, the patch would change this behaviour from conforming to the specification to non-conforming.

I attached a sample with channel configuration "0" which means the channel layout is defined through PCE (program configuration element as in the specification), the sample is correctly identified as 7.1 (non-wide) and is decoded correctly afaict. (QuickTime? apparently fails to decode the attached sample correctly, it seems to assume all 8 channel aac samples as 7.1 wide.)

I realize that my patch is not in accordance with the spec, however my requirements are a bit different, because i deal with Microsofts DirectSHow things, and using the "unusual" wide channel layout causes quite a bit of issues with other components in the DirectShow infrastructure, which is the main reason i changed it.

I do not believe its the right course for ffmpeg itself to change this, instead it should stay true to the spec.

I am closing this ticket as worksforme because I believe your sample is handled correctly by FFmpeg.

I wanted to suggest using -channel_layout 7.1 as a work-around, but the option is currently broken - this is ticket #2163 - and I fear it may not work for aac for some reason, this should be tested as soon as ticket #2163 is fixed.