Ok, I basically figured it out. The problem is that the NinjectResolver BeginScope method returns a new NinjectScope passing in _kernel.BeginBlock () for the constructor. This reassociates the instances from the area that was declared in their bindings to the new activation block.
So, what was once covered by the request is now tied to an activation block.
To get around this, I modified NinjectResolver as follows:
public IDependencyScope BeginScope () {return new NinjectScope (_kernel); }
Then, to keep NinjectScope at the disposal of the kernel itself, I commented on everything in the NinjectScope Dispose block.
As far as I can tell, this should not have much influence. The built-in caching and data collection mechanism will work, as usual, polling the GC and deleting instances in the cache automatically.
I think the crux of the problem here is that WebApi itself is trying to do the job of managing the request scope, but Ninject already has a way to do the job. Two different review mechanisms do not seem to live in harmony.