Well, then I suggest a compromise: fresh the API and release a 0.2 version. During the year, Pattern accurately standardize, and then you can release the cherished 1.0. Why wait so long? There's no hurry, besides, libraries which experienced several major version seem unreliable.

I don't want to split the regex API over multiple traits. I want a single cohesive interface because I think that is easiest to consume. I feel strongly about this.

The current regex crate API has been out in the wild and in use for two years at this point, there's no hurry.

Mandatory arguments better to be in the build function rather than in the constructor.

I don't necessarily agree. If mandatory arguments are in the constructor, then there's no way to misuse the API by "forgetting" to call a method before compilation.

It is advisable to implement the borrow chaining.

Yes, this was brought up above and I agreeish.

Why RegexBuilder::new() takes &str regexp pattern, converts it to String and adds to Vec?

Because &str is the most friendly API. There's no compelling reason I'm aware of to make it generic.

I look at the Regex::find_Iter and expect to see Regex::find_iter_mut, but it is not, so the current name is wrong. Maybe should name similar to the Pattern methods?

What are the semantics of find_iter_mut on Regex? Why does its absence imply the name find_iter is wrong?

The constructor Regex::with_size_limit should be remove, for this using RegexBuilder.

Yes, this is in the RFC. It is being removed.

Maybe should add *_unchecked methods to the Captures?

This is out of scope IMO. If someone can write a meaningful benchmark that would benefit from those methods, then I think I'd be happy to oblige, but we don't need to resolve this for 1.0.

Method Regex::as_str seems odd, because why in the compiled regex keep its textual representation?

Because reading the original string of the regex that was compiled is occasionally useful and doesn't really cost us anything.

Needs rightmost methods like a .find, .rfind, .is_match, .is_rmatch, etc.

Do you mean reverse searching? Maybe one day, but it's out of scope for 1.0.

I think it is worth to rename some of the methods and add more

Yes, I'm going to go over the iterator names and make sure they line up with conventions in std. I struggle with whether to use the Iter suffix because the suffix makes it really easy to distinguish which types are iterators and which aren't when reading the documentation. Although, I suppose there are other ways to solve that problem that don't involve the Iter suffix.