Dear Niall, these are my 2 cents:
I am unaware of anyone using AFIO in production code.
This is how I see it: your library might be included in a Boost release almost in 2016. Those who need asynchronous file i/o on already existing VS2013 projects are already doing "their own thing". I doubt that these projects will be switching to a Boost 2016 release, and really doubt that these projects are going to switch "their own thing" for AFIO. Two years ago this might have made sense to some people (I know it did not make sense to some), but right now I think it is worth asking: Do you happen to know of any particular VS2013 project willing to do this? To me the single most important thing is that _you_ are going to be maintaining this library for the next 10 years if it gets accepted. Having to maintain a library filled with macros and hacks for the sake of old compiler support is painful enough. Having to do this twice for 2 different APIs is a lot of work. So I wish that you would focus on the API you want to have with the hope that this will keep you motivated longer and the whole community will benefit more in the long term.
From what I understood, a different interface for VS2013 can be provided either as an extension, or as a different library. Such a library/extension doesn't even need to be part of Boost if you don't want it to, and maybe those willing to use your library with VS2013 might take over the maintenance of this extension giving you time to work on other things.
TL;DR: cut out all of the C++11 legacy code and save your future self a lot of time: require clang 3.7, C++14, and submit a minimal library that you are willing to maintain for the next 10 years. Best regards and keep up the good work, I can't wait to see those constexpr futures in action!