1. I could just use the Pimpl idiom. However, I see problems with use of vanilla Pimpl as it is standardly defined because I want users of my library to be able to inherit from myFramework::Sprite et al to make their-game specific classes but C++ does not allow inheritance from objects only inheritance from classes. If a myFramework::Sprite is exposed to the user via a creation function that creates a private implementation of a public myFramework::ISprite interface (or whatever) there would be no direct way for the user to inherit from/ implement ISprite while still getting the default myFramework::Sprite behavior. They would have to implement UserSprite that inherits from ISprite but also has a member variable UserSprite::impl that is created via the Sprite creation function my library exposes and then would have to forward calls to UserSprite to UserSprite::impl as appropriare. This just seems to push too much complexity on to the user for my tastes.
2. Just forward declare sfml::sprite in myFramework_Sprite.h, have each myFramework::Sprite have a std::unique_ptr<sfml::Sprite> in the header, and include and use it in myFramework_Sprite.cpp. Sfml leaks out in this case as a name in a header. Also not totally sure this would even work ... can you forward declare a namespace marked-up name? (anybody?)
3. Same as 2. but just make myFramework::Sprite::impl be a void* and then cast to sfml::Sprite* in the cpp file. This is untidy, un-C++ like e.g. would not be able to use an std::unique_ptr<T> (right?), would have to do a cast plus delete in the destructor.
4. Have myFramework::Sprite implement an abstract interface, say, ISprite but also have an "impl" member variable of type unique_ptr<ISprite> and then in the CPP file implement a private class wrapper around sfml::Sprite and forward calls to it in the implementation of myFramework::Sprite. Essentially this is doing work similar to 1. but hiding it from the user. This is what I am currently doing it my codebase, it works but is verbose ... and after a while it just struck me that when it comes down to it this is essentially the same thing as 3., the void* solution, but with some interfaces throw in to disguise that fact and make me feel better about myself
5. Make myFramework::Sprite have a private impl member variable of type boost::any, or my only implementation of a boost::any analog.

The other option is throw out one of the premises that led to the line of thought in 1. to 5. above.

6. Use vanilla Pimpl but don't allow, expect, or require users of the framework to inherit from framework classes. Require users to do all callbacks, extensions, and customization of framework objects via composition. I think this would work but it's hard to get my head around. Say you have a UserSprite that has-a framework sprite and you register the framework sprite to receive generic gameloop updates and register it to recieve mouse input updates. If the form of the mouse input callbacks and the generic gameloop updates are std::function<void(myFramwork::Sprite&, ...)> or whatever in that callback there would be no trivial or beginner-friendly way for the callback to retrieve the UserSprite given the myFramwork::Sprite at call time. One could do it by capturing the std::shared_ptr<UserSprite> in lambdas installed in the mouse callback hooks and the generic gameloop hooks, which I think would work, just seems ... i don't know ... confusing?

Thoughts appreciated...

Sort of tangential to the topic of API design, but one thing to note is that you may be required by the license of your dependencies to advertise that they are used in your framework.

This doesn't appear to be the case with SFML, but there are some common licenses you may encounter that have this requirement.

I'm not big on hiding this sort of thing from your customers. The code aspects aren't so great, but where you are really letting yourself in for a world of pain, is in needing to provide perfectly working development/release toolchains for every platform under the sun (i.e. you need to provide out-of-box toolchains for Android and iOS, since your customers can't get at the dependencies to do it themselves).

I'm not big on hiding this sort of thing from your customers. The code aspects aren't so great, but where you are really letting yourself in for a world of pain, is in needing to provide perfectly working development/release toolchains for every platform under the sun (i.e. you need to provide out-of-box toolchains for Android and iOS, since your customers can't get at the dependencies to do it themselves).

Hadnt really thought about this in that am only going to support Win32 and iOS out of the box because that is what I need personally and it doesnt seem complicated in these two cases (famous last words, maybe). But as you say Linux and Android might be a can of worms ... I don't know a lot about either platform, in terms of game programming anyway in the case of linux.
However to me, implications on the complexity of implementation aside, this is what I personally want out of some I kinds of frameworks: I want someone else to get this kind of stuff right for me. I was planning on having a Python script that will generate a solution/project files etc for you when you start a new project with this game framework. That script will be parametrized in part on platform(s) you want to support. It would just copy in the framework binaries and set up the solution/projects to statically link to them.

If however you want access to my usage of SFML and OpenAL and libJpeg and zlib etc. you can always pull all the code from github and build that way, changing whatever you like. That would just not be the default usage pattern. My general thought is your average user doesnt care that I am using SFML texture wrappers in there any more than he or she cares that I am using dropbox's Json11 to parse spritesheet metadata Json -- so why have a design that makes those headers and those binaries public to average users? if it is difficult to do this then so be it and maybe I will have to change my decision here for pragmatic reasons but I still think it is a laudable goal.

I could just use the Pimpl idiom. However, I see problems with use of vanilla Pimpl as it is standardly defined because I want users of my library to be able to inherit from myFramework::Sprite et al to make their-game specific classes but C++ does not allow inheritance from objects only inheritance from classes.

Sounds like you (or I!) have misunderstood how to implement the Pimpl idiom. I don't see any reason why they can't inherit from your public class given that it would be responsible for creating the private class (eg. in the constructor) and it's the private class that deals with SFML. All the issues regarding inheritance and ensuring behaviour is correct are separate from how the behaviour is eventually implemented.

Yeah, I've looked into it and have come to the conclusion that my usage of the term "pimpl" is wrong or nonstandard. I thought it generally meant when you expose publically only an abstract interface and a public static member function that creates an instance of an object that implements the interface using a private class often defined completely in a cpp file. The factory function creates one of those thingies and returns that but as a pointer to the interface. This is a way a lot of algorithms are implemented in OpenCV and extensions people write to OpenCV for example (which I use a lot at work). I got it in my head that this is what people mean by "pimpl" but according to wikipedia pimpl is close to what I describe in 2. or 3. in the original post.