I agree partial type is maybe not the best name for this thing. I think type constructor would be a good name if that's the only thing this did (which is pretty much the only thing it does right now). I imagine in the future if we wanted to inspect "generic requirements of a generic type", then this would probably happen on partial types and wouldn't make sense with the name type constructor. Generic type is an interesting name because it fits nicely with the use case above, but it gets a little weird because the type doesn't necessarily need to be generic to have a "GenericType" (e.g. Int has a "GenericType"). That being said, I'm all ears for a better name 
Keypath introspection is definitely a much requested featured and I imagine we'll eventually want to be able to do that (either directly on keypaths, or some new facility in this Reflection module). I've held off on designing anything that space so far and only focused on what's being proposed.
The second library on that list happens to be one I made a couple of years ago That library is intended to be a low level interface to the Swift runtime which allows for higher level APIs like the ones being proposed. The first library has some similarities (Property vs Field), but it looks like it was mostly used to get/set properties via string name (which one can do here by comparing Field.name and using Field.keyPath) and construct instances of types at runtime (using unsafe bits that doesn't always work).
-disable-reflection-metadata removes the reflective capabilities of Field and Case, so every other API available on Type and PartialType would still work because it uses information required by the runtime (not strippable).
Yeah, Field.offset should probably return nil in that case. We can for sure add all of the MemoryLayout APIs and more onto Reflection.Type, but it does feel redundant because you can get the same info from 2 separate facilities.
Yeah, those placeholder types are probably better to use than [Int: Int]. Thanks! Having the placeholder in the textual representation is also a nice improvement here. I made the textual representation a separate API under name because I was unsure how common it is to access a type's description, but if people think that's a better place to put this, then by all means I imagine description would look like Type<_, _> and debugDescription could look like Module.Outer<_>.Type<_, _>?
I included all of the @usableFromInline, @inlinable, and @frozen as part of the detailed design because I wanted evolution to clearly see what we're committing to as ABI. As you can see, Type stores a value of type Metadata which is why I didn't name it as such (that API will be proposed at a later date).