The existing Data.Map and Data.Set define a de-facto API. This API is important because many existing haskell programs use it. (See the corresponding haddock documentation for a "definition" of the API.)
Implementors of alternatives to Data.Map and Data.Set are advised to stick as closely as reasonably possible to the existing API. This would allow users to switch between implementations by just changing their import directive.
However, there are legitimate reasons not to strictly stick to the same interface. Should an implementor choose to do so, minor changes, or not-misleading changes, should be considered first. For example:
Drop a function
Change the context (constraints) of a function type
Harmless changes in behaviour (ie. different asymptotic performance)
A important case, discussed at length in the mailing list, concerns left-biasing in Sets and key-sets of Maps in the presence of non-structural equality. Assuming structural equality (or not enforcing the left-bias) is considered a minor change, because few people actually rely on it in their programs.
Misleading changes are strongly discouraged:
Changing the type of a function, besides the constraints.
Gather alternative collection implementations. Those must pass the regression tests. Note that this implies that they conform to the naming conventions already in place, or that compatibility layers are added.
Candidates for inclusion:
Adrian Hey's AVL trees
Use AVL trees implementation as default
Performance tests should compute the complexity bounds automatically.