I see the usage here is intended to be:

manager = ReporterManager(...)

manager.render("string_view", "Hello world!")
manager.render("detail_view", {"foo": true})

This is unwieldy, ideally the render function should be smart enough to figure it out for us (much like how print and rich simply figure it out for us):

manager = ReporterManager(...)

manager.render("Hello world!")
manager.render({"foo": true})

Hey, Ken!
The reason we decided to have two methods (one printing strings, one tabular data) in the first place is because a single conda command prints data in different forms depending on the flags used with it.
For example, conda info --base simply prints a string (the root prefix), whereas conda info prints tabular data (data printed in two columns; key, value pairs).
You are suggesting that reporter_manager.render(data) should itself look at the context, flags passed etc, and print the data in the appropriate format.
For example the render method will find that --base flag has been passed, so instead of printing "key: value", it will print str(value). Therefore there will need to be some if: else: logic in the render method.
But the render method in the ReporterManager class is supposed to be a general class method that can be used by any conda command.
It is possible that some other conda command used with --base flag DOES NOT print a string, but a key-value pair.
Therefore the render method should not be responsible for everything.

No, I do not expect the render method to know anything about the context, nor should it contain any logic to determining what is rendered.

I expect render to know that a str is a string and how to print it (using string_view). It should also know that a dict is a mapping and how to print it (using detail_view).

I expect something like the following to happen:

def conda_info(args):
    info = {...}

    if args.base:
        # conda info --base
        manager.render(info["base"])
    elif args.envs:
        # conda info --envs
        manager.render(info["envs"])
    elif ...:
        ...
    else:
        # conda info
        manager.render(info)

Hey, Ken!
I now understand your suggested changes better. Thank you.

I expect render to know that a str is a string and how to print it (using string_view). It should also know that a dict is a mapping and how to print it (using detail_view).

The render method is intended to point to a type of "template". The methods that we’ve defined on the ReporterHandler classes are these templates. For now, we only have "string_view" and "detail_view" which depend on the data type they receive.
But not all of these "templates"/"views" will necessarily depend on the data type passed in. Therefore we do not want to create any map between which data type was passed in and which "view" method gets called.

Does that make the reasoning behind this implementation clearer? :)

But not all of these "templates"/"views" will necessarily depend on the data type passed in.

If that's the case, a compelling example is necessary to sway my opinion. The implementation and the arguments for why we want it this way look and sound like we are over engineering. It's ok for us to over engineer but we need to have documented examples for why we are doing this.

In any case, I expect the vast majority of renders to be based on the data type. So the format/template name should at least be an optional key and when not provided it is determined from the data type.