I have removed the two lines on checking warnings, since this method only does the smaller part of the work of checking for warnings and thus this might not be as relevant here. But it would actually be nice, to do this all in one place. The rest of the warning checking is done in MethodMetadataRequest._route_params().

For another PR, I was thinking of trying to put all the warning checking into here (MetadataRouter.route_params()) and then documenting it with:

Metadata requests are also validated and may trigger warnings for newly added 
metadata. This includes the router’s own requests if it also acts as a consumer.

Would that be a good idea?

I think this was wrong before.

Finding different words for "router objects" to prevent confusion with this classes' own name.

The part explaining that MetadataRequest objects and MetadataRouter objects are aligned during a call to process_routing() is crucial to communicate the general idea.

This seems to be a copy-paste from the docstring of request_is_valid and even though a "str" is an "object", it'll help users more to be more specific here. I would also rename the item param into name.

But do request_is_alias and request_is_valid need to be in the public API at all?

it's still an object here, particularly, anything in VALID_REQUEST_VALUES. Also, this function checks if the given object is a string, so the input doesn't have to be a string.

Why the brackets?

That was, I think, supposed to express that third party developers and users who implement custom meta-estimators should also implement a get_metadata_routing method, while it is not strictly required to write a scikit-learn compatible estimator.

I have now re-phrased it to only match scikit-learn's native estimators. A guide on how third party developers can use scikit-learns metadata routing API is already existing in the user guide and better explained there as well.

That was, I think, supposed to express that third party developers and users who implement custom meta-estimators should also implement a get_metadata_routing method, while it is not strictly required to write a scikit-learn compatible estimator.

I have now re-phrased it to only match scikit-learn's native estimators. A guide on how third party developers can use scikit-learns metadata routing API is already existing in the user guide and better explained there as well.

Yea, exactly! It would look something like this:

{'estimator': {'mapping': [{'caller': 'fit', 'callee': 'fit'}, {'caller': 'predict', 'callee': 'predict'}, {'caller': 'score', 'callee': 'score'}], 'router': {'fit': {'sample_weight': True}, 'predict': {'groups': None}, 'score': {'sample_weight': None}}}}

Though, now I am wondering why the second part is called "router" when in other parts of the docs the same concept is referred to as "request"...

Do you think it makes sense to change that, too?

@adrinjalali, would you verify this can be changed? What would be your take on that?

To be honest, I had spared that out until now. But you are right to ask me to clarify this as well. So I have tried to re-write this paragraph. Please let me know what you think. :)

My understanding is that each consuming estimator communicates their requests by their _get_metadata_request method, which in the simplest case inspects the methods' signatures and builds a dictionary with all the requested metadata from it, which is then stored as an estimator's _metadata_request attribute. This attribute is created while running set_{method}_request via RequestMethod.__get__ (not sure how it gets there though, just inspecting the output of my debugging session).

Something like metadatarequest.fit.add does not exist in the code as far as I can tell. I would assume the syntax has changed and metadatarequest.fit.add(param="sample_weight", alias="my_weights") refers to method_metadata_request.add_request(param=prop, alias=alias), which - yes - is done per method and add became add_request.

In my current understanding, it will mostly be an estimator and I wonder more about how this would work / what could happen for this to be another MetadataRequest.

If you look at the example for developers writing their own meta-estimators, there we would add self into .add_self_request() when the MetadataRouter is build:

class RouterConsumerClassifier(MetaEstimatorMixin, ClassifierMixin, BaseEstimator):
    def __init__(self, estimator):
        self.estimator = estimator

    def get_metadata_routing(self):
        router = (
            [MetadataRouter](https://scikit-learn.org/stable/modules/generated/sklearn.utils.metadata_routing.MetadataRouter.html#sklearn.utils.metadata_routing.MetadataRouter)(owner=self.__class__.__name__)
            # defining metadata routing request values for usage in the meta-estimator
            .add_self_request(self)
            # defining metadata routing request values for usage in the sub-estimator
            .add(
                estimator=self.estimator,
                method_mapping=[MethodMapping](https://scikit-learn.org/stable/modules/generated/sklearn.utils.metadata_routing.MethodMapping.html#sklearn.utils.metadata_routing.MethodMapping)()
                .add(caller="fit", callee="fit")
                .add(caller="predict", callee="predict")
                .add(caller="score", callee="score"),
            )
        )
        return router

Avoiding the word "store" for MetadataRouter, since it gets re-build on demand and is not attached to any object.

Okay that makes more sense, and combined with your explanation in #31419 (comment) I understand better.
The MetadataRequest use case is indeed intriguing. I can imagine 'how' it could work but not sure in what situation it would be used.
Anyway thanks!

Rephrased to avoid reading 'request' as a noun and to emphasize that this method configures metadata handling not definitely passes any.

they're created at construction time

I know what you mean here, but it's somewhat misleading.

I would maybe phrase is as:

The MetadataRouter objects are never stored and are always recreated whenever
the object's get_metadata_routing method is called.

it's still an object here, particularly, anything in VALID_REQUEST_VALUES. Also, this function checks if the given object is a string, so the input doesn't have to be a string.

params is a list of metadata names

I don't think we've had a usecase for it being anything other than self. You could argue that, that information can be retrieved from owner and instead of having a add_self_request we could add a owner_is_consumer to the constructor.