TL;DR: Rename URLSearchParams to QueryParams.

I've discussed with @jeffbcross that it would be wise to rename the class, as we are considering having a behaviour which differs from the WHATWG's version of the interface --- naming this differently could help minimize confusion when using the API.

Some ideas:

-SearchQuery
-SearchParameters
-SearchParams

All missing the leading URL and maybe standing out from the family of interfaces derived from https://url.spec.whatwg.org.

The behaviours discussed, which some may agree or disagree with, include the following:

• An explicit merge method (which I think would be valuable to propose to the editors of whatwg/url. If the WHATWG did in the future accept a proposal like this, it may be possible to deprecate and remove the in-angular URLSearchParams and rely on the native implementation instead, in the future. So that's something!

Semantic issue: Tab Atkins Jr isn't keen on the fact that sometimes, you want to merge by appending to existing values (a MultiMap behaviour) and sometimes you want to replace existing values (a Map behaviour) --- but doesn't believe there's value in providing a way to specify a schema. Having two methods would certainly require being explicit, though.

OR

• Implicitly merging during RequestOptions.merge(), rather than the WHATWG's strategy of replacing the original query entirely (currently, but possibly not in the future, for all URLs which are associated with the URLSearchParams object). It should be possible to implicitly merge this way even if the WHATWG's version of the object were used, but may not be.

Any thoughts or suggestions are welcome