As part of the query refactoring we are trying to make support for boost and _name in our queries more generic and consistent (#10776) as it is currently copy pasted in all query parsers and builders, sometimes forgotten, and error prone. While working on that, I realized that _name and boost are supported slightly differently in the json depending on the type query. The main difference, besides bugs, is that some queries support both within the top level query object:

{
  "multi_match" : {
    "query" : "test",
    "fields" : ["field1", "field2"],
    "_name" : "query_name",
    "boost" : 10
  }
}

while others support them within the inner object named like the field that gets queried:

{
  "term" : {
    "field_name" : {
      "value" : "test",
      "_name" : "query_name",
      "boost" : 10
    }
  }
}

or even the following:

{
  "term" : {
    "field_name" : "value" : "test",
    "_name" : "query_name",
    "boost" : 10
  }
}

The following is a summary of all of the queries and their behaviour:

** : queries that support the inner object named as the field that gets queried, but support _name on the top level object instead.

All of the queries that support _name and boost within the inner object do so in their long version. The corresponding short version usually doesn't support _name and boost, but only a single field in the form field: value.

1. The main question is where should the _name be supported. Should it always be in the top level object, as I was expecting without looking at the code, or does it make sense to wrap everything in the inner object if present?

2. Queries that don't support _name at all: boosting, constant_score, function_score, geohash_cell, limit, match_all, span_multi, type. Support for _name needs to be added to these?

3. Queries that don't support boost: indices, simple_query_string (PR opened), span_multi. Support for boost should be added to these?

4. Filters that don't support boost: and, bool, exists, geo_bbox, geo_distance, geo_distance_range, geohash_cell, geo_polygon, limit, missing, not, or, script, type. Now that filters and queries are merged, can these be used as queries? If so would the boost make sense if it was supported here too?

5. The following are inconsistencies that surely need to be fixed, according also to outcome of this discussion:

• GeoShapeQueryBuilder doesn't support boost, but GeoShapeQueryParser parses it (fixed in Java api: add missing support for boost to GeoShapeQueryBuilder and TermsQueryBuilder #11810).
• PrefixQueryParser supports _name in both short and long version, boost only in long version.
• RegexpQueryParser supports _name in both short and long version, boost only in long version.
• RangeQueryParser supports_name in the top level but boost in the inner field object.
• TermQueryParser supports both _name and boost in both long and short version.
• TermsQueryBuilder doesn't support boost, but parser parses it (fixed in Java api: add missing support for boost to GeoShapeQueryBuilder and TermsQueryBuilder #11810).