> +# AUTO_INCREMENT field is both standalone and in WITHOUT OVERLAPS
> +create or replace table cars(id int primary key auto_increment,
> +price int, s date, e date,
> +period for p(s,e),
> +unique(id, p without overlaps));
> +insert cars(price, s, e) values (1000, '2018-01-01', '2020-01-01');
> +select * from cars;
> +id   price   s       e
> +1    1000    2018-01-01      2020-01-01
> +update cars for portion of p from '2019-01-01' to '2019-12-01' set price= 1100;
> +ERROR 23000: Duplicate entry '1' for key 'PRIMARY'

uhm, I don't know. I'd expect that here PRIMARY would define
autoincrement values.

> +truncate cars;
> +insert cars(price, s, e) values (1000, '2018-01-01', '2020-01-01');
> +delete from cars for portion of p from '2019-12-10' to '2019-12-20';
> +ERROR 23000: Duplicate entry '1' for key 'PRIMARY'
> +# AUTO_INCREMENT field is non-unique

not sure here. I think here unique should define autoincrement values.
That is, in both cases, the most restrictive index should define.
> +void TABLE::period_prepare_autoinc()
> +{
> +  if (!found_next_number_field)
> +    return;
> + 
> +  key_map::Iterator it(found_next_number_field->part_of_key_not_clustered);
> +  for (uint i; (i= it++) != key_map::Iterator::BITMAP_END;)
> +  {
> +    KEY &key= key_info[i];
> +    if (key.without_overlaps)
> +      return;
> +  }

No, I don't think you need to check *all* indexes that the field is part
of. I believe you should only check the "main" index, the one that
defines autoincrement field behavior. That is only

  if (key_info[s->next_number_index].without_overlaps)
    return;