Let's be specific about which warning we are talking about.

I also wonder if it is worth detailing all public functions this will affect, since whats new is aimed for users, and type_of_target may be less meaningful to a user than e.g., GridSearchCV will no longer give spurious "The number of unique classes is greater than 50% of the number of samples" warning when the number of samples is...etc

How do you find out all the public functions that are affected?

I don't have a clever solution outside of searching in the codebase. Maybe a regular expression search for when classes is passed to type_of_target ? Or something that is not y_* ?
Failing that, just a list of classes/functions that use _get_response_values would be nice.

Like this?

- Fixed a spurious warning that could occur when passing ``estimator.classes_``
  or similar arrays with many unique values to classification utilities.
  The warning came from :func:`sklearn.utils.multiclass.type_of_target` and has
  now been suppressed when the input is not a true target vector.
  The warning message was: "The number of unique classes is greater than 
  50% of the number of samples."
  This could appear in tools that internally validate classification outputs,
  such as :class:`~sklearn.model_selection.GridSearchCV`,
  :func:`~sklearn.model_selection.cross_val_score`,
  :func:`~sklearn.metrics.make_scorer`,
  :class:`~sklearn.multioutput.MultiOutputClassifier`,
  and :class:`~sklearn.calibration.CalibratedClassifierCV`.

  By :user:`Sascha D. Krauss <saskra>`

Given the large amount of potentially affect public classes and functions, I'm not sure it's worth trying to list them all. It was just an unexpected warning, not a critical bug. Since type_of_target is a public function I think it's fine for the changelog to only be about it.

Fair point, what about something like:

- Fixed a spurious warning (about the number of unique classes being
  greater than 50% of the number of samples) that could occur when
  passing `classes` :func:`utils.multiclass.type_of_target`.

Note you don't need the sklearn at the start in whats new entries.

Could we add a note here to explain why we add the '0' at the end?

And maybe we could keep the original y = np.arange(25) and check that this does not raise a warning?

However, the original y = np.arange(25) now raises a warning because the condition y.shape[0] > classes.shape[0] is not fulfilled, but y.shape[0] == classes.shape[0]. Hence the second zero in the new array in the test, so that you at least have a single class with two samples. The whole point was to prevent the warning from being issued incorrectly if the function is only called with the unique class list instead of the real list of class labels per sample - hence the original idea was also an argument to suppress the warning for this case.

So should we rather adapt the test or treat the case y.shape[0] == classes.shape[0] in type_of_target differently?

Could we add a note here to explain why we add the '0' at the end?

+1
Let's add a comment to explain that we create an array with almost all classes represented only once except 0 represented twice.

And maybe we could keep the original y = np.arange(25) and check that this does not raise a warning?

However, the original y = np.arange(25) now raises a warning because the condition y.shape[0] > classes.shape[0] is not fulfilled, but y.shape[0] == classes.shape[0]

@saskra I think @lucyleeow is correct. Now the np.arange(25) case won't raise the warning because we special cased y.shape[0] == classes.shape[0] so we can check that indeed no warning is raised. Something like the following that we'd put at the end of the test.

# More than 20 samples but only unique classes, no warning should be raised
y = np.arange(25)
with warnings.catch_warnings():
    warnings.simplefilter("ignore", UserWarning)
    type_of_target(y)

please revert unrelated line removal