nit: I think it would be clearer here to keep those cases (parameters vs. pseudo-parameters) better separated for clarity. E.g. explicitly handling resolve_pseudo_parameter when the value starts with a AWS::... instead of using it as a fallback here. (same applies for the cases further below)

Thanks for the suggestion. It's implemented int #11693

Perhaps we should be a bit more deliberate in trying to resolve pseudo parameters? E.g. only try to resolve pseudo parameters if ref_name starts with AWS::?

I don't really like the way we are treating two different data types (dicts when the map name is a parameter, or a str when the ref is a pseudo parameter) and trying the different options depending on the type. I would prefer to be more explicit that the two sources of information should be treated differently.

In that case, we can be more specific about the error message below as well. E.g. something like:

if ref_name.startswith("AWS::"):
    map_name = resolve_pseudo_parameter(...)
    if map_name is None:
        raise TemplateError(f"Invalid pseudo parameter '{ref_name}'")
else:
    param = parameters.get(ref_name)
    if not param:
        raise TemplateError(
            f"Invalid reference: '{ref_name}' does not exist in parameters: '{parameters}'"
        )
    map_name = param.get("ResolvedValue") or param.get("ParameterValue")

WDYT?

Awesome. It's a lot better. I put it in #11693

Can the map name ever be a pseudo parameter?!

Yes. Takes a bit of work but AWS supports AWS:: in the mapping name. Please checkout #11693