Proposed resolution:

This wording is relative to N4567.

1. Change [futures.unique_future] as indicated:

   -3- The effect of calling any member function other than the destructor, the move-assignment operator, share, or valid on a future object for which valid() == false is undefined. [Note: Implementations are encouraged to detect this case and throw an object of type future_error with an error condition of future_errc::no_state. — end note]

   namespace std {
     template <class R>
     class future {
     public:
       […]
       shared_future<R> share() noexcept;
       […]
     };
   }
   

   […]

   shared_future<R> share() noexcept;
   

   -12- Returns: shared_future<R>(std::move(*this)).

   -13- Postcondition: valid() == false.

   […]

[ 2016-08-03 Chicago ]

Fri AM: Moved to Tentatively Ready

future::share() is not noexcept, it has a narrow contact requiring valid() as per the blanket wording in [futures.unique_future] p3. Its effects, however, are return shared_future<R>(std::move(*this)), which is noexcept as it has a wide contract. If the source future isn't valid then the target shared_future simply won't be valid either. There appears to be no technical reason preventing future::share() from having a wide contract, and thus being noexcept.