{
  _repository {
    content(id: 1234) {
      fields {
        value {
          ... on TextLineFieldValue { text }
        }
      }
    }
    location(id: 1234) {
      pathString
    }
  }
}
...

This was the first GraphQL implementation for eZ Platform, that was replaced by the generated schema, that suffers from several drawbacks:

• It has bad DX (you need to use fragments as in the example above to distinguish fields)
• It isn't finished (fieldtypes are hardcoded)

The generated schema does the same thing, and more:

• fields values, the most important part of fields, is exposed through the field's identifier
• content info can still be accessed through _info
• locations are also available, as well as URL aliases

Overall, most of the elements from _repository could be removed: location, content, searchContent, user, userGroups... even contentType / contentTypes are questionnable, as they are available from <contentTypeGroup>._types.<identifier> with a more convenient structure.

This "repository like" approach, where you don't depend on the configured types, is still relevant, but not for the mobile app / headless site approach. It should be reconsidered, and finished properly before it is released.