Template deduction with leading pack expansion fails on GCC 4.8.2 x86 (devtoolset-2) only

Here's an MCVE from some template metahackery in my C++11 project:

#include <functional>

struct Foo {};

template <typename... T>
void expect(std::function<void(const T&)>&&... onSuccess)
{
    expect<T...>(
        std::forward<std::function<void(const T&)>>(onSuccess)...,
        0,
        [](){}
    );
}

template <typename... T>
void expect(
  std::function<void(const T&)>&&... onSuccess,
  const time_t timeout,
  std::function<void()>&& onExpiry
)
{
    // ...
}

int main()
{
    expect<Foo>([=](const Foo&) {}, 42u, [=](){});
}

It builds fine in GCC 6.1^{(using Coliru)}, GCC 4.8.5 and GCC 4.8.2 x86_64^{(using GodBolt)}, but when I plug it into my development environment (which is GCC 4.8.2 via devtoolset-2 on CentOS 6 x86) I get errors:

[root@localhost ~]# g++ test.cpp -std=c++11 -o test
test.cpp: In function ‘int main()’:
test.cpp:27:47: error: no matching function for call to ‘expect(main()::__lambda1, unsigned int, main()::__lambda2)’
   expect<Foo>([=](const Foo&) {}, 42u, [=](){});
                                               ^
test.cpp:27:47: note: candidates are:
test.cpp:6:6: note: template<class ... T> void expect(std::function<void(const T&)>&& ...)
 void expect(std::function<void(const T&)>&&... onSuccess)
      ^
test.cpp:6:6: note:   template argument deduction/substitution failed:
test.cpp:27:47: note:   mismatched types ‘std::function<void(const T&)>’ and ‘unsigned int’
   expect<Foo>([=](const Foo&) {}, 42u, [=](){});
                                               ^
test.cpp:16:6: note: template<class ... T> void expect(std::function<void(const T&)>&& ..., time_t, std::function<void()>&&)
 void expect(
      ^
test.cpp:16:6: note:   template argument deduction/substitution failed:
test.cpp:27:47: note:   cannot convert ‘<lambda closure object>main()::__lambda1{}’ (type ‘main()::__lambda1’) to type ‘time_t {aka long int}’
   expect<Foo>([=](const Foo&) {}, 42u, [=](){});

[root@localhost ~]# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-2/root/usr/libexec/gcc/i686-redhat-linux/4.8.2/lto-wrapper
Target: i686-redhat-linux
Configured with: ../configure --prefix=/opt/rh/devtoolset-2/root/usr --mandir=/opt/rh/devtoolset-2/root/usr/share/man --infodir=/opt/rh/devtoolset-2/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,fortran,lto --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-i686-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-i686-redhat-linux/cloog-install --with-mpc=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-i686-redhat-linux/mpc-install --with-tune=generic --with-arch=i686 --build=i686-redhat-linux
Thread model: posix
gcc version 4.8.2 20140120 (Red Hat 4.8.2-15) (GCC)

I can work around this by moving onSuccess to after timeout and onExpiry in the second overload, but I think the original ordering is easier for developers to use and would rather keep it if I can.

So is there any other way?

And, for bonus points, what's actually going on?

A closer look at the GodBolt interface shows that "4.8.2 x86_64" is actually 4.8.5 (and "4.8.1 x86_64" reproduces), so this would appear to be a simple GCC bug after all (though I can't see it on Bugzilla).

I'll just go with the reordering workaround then, keeping the variadic argument to the right.