position inconsistency when using _analyze API with or without index name

[dadoonet]

Elasticsearch version (bin/elasticsearch --version): 6.2.2
Steps to reproduce:

Consider the following

DELETE temp
PUT temp 
GET temp/_analyze
{
  "analyzer": "standard", 
  "text": [ 
    "a", "b"
  ]
}

It gives:

{
  "tokens": [
    {
      "token": "a",
      "start_offset": 0,
      "end_offset": 1,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "b",
      "start_offset": 2,
      "end_offset": 3,
      "type": "<ALPHANUM>",
      "position": 101
    }
  ]
}

Position of the 1st term of the second text is 101 which is correct because we don't want to be able to match phrase like a b.

Now the same _analyze but with no index name:

GET _analyze
{
  "analyzer": "standard", 
  "text": [ 
    "a", "b"
  ]
}

It gives:

{
  "tokens": [
    {
      "token": "a",
      "start_offset": 0,
      "end_offset": 1,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "b",
      "start_offset": 2,
      "end_offset": 3,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

Position of the 1st term of the second text is 1 which is incorrect.
It leaves the impression that a match phrase could work on a b.

Not important though as indexing a document is always happening within an index but I'm feeling that this _analyze API is giving inconsistent results. May be we should fix it?

cc @jpountz

[elasticmachine]

Pinging @elastic/es-search-aggs

[umeshdangat]

The reason for the difference in positionIncrementGap is because for the index based case NamedAnalyzer is used which overrides getpositionIncrementGap() vs for the non-index based case StandardAnalyzer is used directly from lucene.

The code that makes this decision is here

Lucene defaults positionIncrementGap to 0 in all analyzers, so if we desire non default lucene behavior for all analyzers the code for setupAnalyzers might need to change to not return vanilla lucene analyzers but ones that override the getPositionIncrementGap.

I am not super familiar with this code so I am not sure if what I suggest is even desired or correct behavior

cc: @jpountz @dadoonet

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)