On Debian pc x86-64, master (updated today), I reproduce this behaviour.

Now just some ideas :
1) Since what you said here http://cgit.freedesktop.org/libreoffice/core/commit/?id=80c235510aeb19d4df6a07be7499e70122313bbf, it could be useful we avoid this kind of things :
if ( pTableExp->getChild(6)->count() > 0 || pTableExp->getChild(7)->count() > 0 || pTableExp->getChild(8)->count()

Now I know it's easy to say, less easy to do :-)
egrep "getChild[0-9]" may be a good start

2) 
Context :
i runned on gdb to better understand how it works. I understood that fields are inserted in designquery by :
"InstallFields" located in "dbaccess/source/ui/querydesign/QueryDesignView.cxx" (all the functions quoted are in this same file)

then order of columns is added by "GetOrderCriteria"

Both functions are called by "InitFromParseNodeImpl"

Here are the interesting lines :
   2351                         OTableFields::iterator aIter = aList.begin();
   2352                         OTableFields::iterator aEnd = aList.end();
   2353                         for(;aIter != aEnd;++aIter)
   2354                         {
   2355                             OTableFieldDescRef pEntry = *aIter;
   2356                             if(pEntry.is() && pEntry->GetFieldAlias() == aColumnName)
   2357                                 pEntry->SetOrderDir( eOrderDir );
   2358                         }
   2359                     }

So we search the column with the iter loop and add the sort once the column is found. (it explains the pb we have) 


What about doing that ?
if pNode->count() = 1 (ie there's only 1 field in ORDER BY), we let the current behaviour, it's sufficient and correct.

else : (order by list contains more than 1 element)
we search the column with the iter and once found :
- we clone it at the end of aList
- add order one the cloned element
- remove visible attribute of the cloned element

So we would have the columns with visibility first, then columns with order ("in good order") with no visibility.
 
Hope I was clear :-)

(In reply to comment #1)

> What about doing that ?
> if pNode->count() = 1 (ie there's only 1 field in ORDER BY), we let the current
> behaviour, it's sufficient and correct.
> 
> else : (order by list contains more than 1 element)
> we search the column with the iter and once found :
> - we clone it at the end of aList
> - add order one the cloned element
> - remove visible attribute of the cloned element

I'm implementing the following:

Sorting columns s=(s_1, s_2, s_3, s_4, ..., s_n)
Visible columns v=(v_1, v_2, v_3, ... v_p)

Let p = (s_1, s_2, ..., s_i) be the longest prefix of s that is a subsequence of v, i.e.:

 s_1 = v_j1
 s_2 = v_j2 && j2 > j1
 s_3 = v_j3 && j3 > j2
 etc


We put the sorting order directly on columns s_1, ... , s_i. We duplicate at end in invisible mode columns s_{i+1} to s_n.

Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=470feb03f11e015b69fc5df11bd141f536eb8c91

fdo#47370 properly duplicate (invisible) out-of-order sort columns

Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e0be5ebd688a5e8c2faa8f097f104c89139efeb&g=libreoffice-3-5

fdo#47370 properly duplicate (invisible) out-of-order sort columns


It will be available in LibreOffice 3.5.2.