Summer '15 is going to include the GA release of Custom Metadata Types. See Introducing custom metadata types: the app configuration engine for Force.com
Are Custom Metadata Types intended as a complete replacement for Custom Settings?
I gather from the article linked above that the big advantage to Custom Metadata Types is that a baseline collection of metadata records can also be deployed in packages.
Are there other advantages? Such as support for lookup relationships or protected values that can only be accessed my code within the managed package? Is there such a thing as hierarchy custom metadata types?
Are there advantages to using Custom Metadata Types with respect to limits? In particular SOQL limits?
See also: How to use custom metadata types to save years of development on app configurations
Best Answer
I’m the original inventor of and lead developer for custom metadata types.
Although we have a variety of use cases in mind, custom metadata types are primarily intended to let you develop peers of Salesforce standard metadata types, such as custom fields, tabs, or workflow rules (obviously in this first release we don’t have the power required to duplicate all the functionality in these types).
Just as you can’t perform CUD on such types in Apex today (you can’t create a new tab, modify a custom field, or delete a workflow rule in Apex), you can’t yet perform CUD on custom metadata types in Apex, short of a metadata API callout. You can help us get that feature prioritized by voting for the idea here. To see how to create tooling using Apex for a custom metadata type, you can look at Jean-Baptiste Pringuey’s sample “configurator.”
Testing is a tricky question, which I address in a blog post I just posted. The use case you describe is definitely a legitimate one. There's been a fair bit of demand for configuration visibility to ftests. See the idea Custom Settings should be treated as a Setup Object for APEX Tests
There’s a lot more planned for custom metadata types than custom settings on steroids. App configurations that don’t have to be re-created in every environment and that can respect managed state (so you can have some that are not deletable or mutable by subscribers) was just a starting place that filled a known need. Aaron’s second blog post gives you a taste of things to come in the near term (safe harbor applies, of course).
Winter `16 features
Layoutable UI for entering and updating records is one of the big features that came out in Winter -- take a look at Custom metadata types: they’re money; actually, even better!
Record-level protection of configuration (as opposed to hiding the entire type, which is both a custom settings and a Summer CMT feature) is another.
The third big feature is field-level control over who can edit values. By setting a field to subscriber editable, you'll be able to default the value in a package and let customers change that value if they need to.
More recent features
It's been a while!
Custom Metadata types now support (as of Summer 17):