Taking a look at crm_map_element_name...

If I simply remove all the calls to that function and replace them with xml->name, CIB files with <master> tags will fail to make it through formatted output. I think what's happening is that xml->name must still be "master", but get_resource_type maps that string to the correct pe_obj_type, so the right kind of object is created.

I don't want to mess with what gets stored in xml->name. If I change that, I'd break any external users that might rely on it. For instance, someone could be constructing an xpath string that includes "master".

On the output side, then, I want to key off the object type and not the XML name. Right now, we are passing a string like "clone" or "primitive" to out->message() to tell it which resource's message to use. We actually already have a function that turns pe_obj_type into a string - get_resource_typename. Unfortunately, it's deprecated and not used anywhere.

I could bring that function back to life.

An alternative would be to have a multiplexing formatted output function - something like this:

static int resource(pcmk__output_t *out, va_list args) {
    pe_resource_t *rsc = va_arg(args, pe_resource_t *);

    if (rsc->variant == pcmk_rsc_variant_primitive) {
        return out->message(out, "primitive", args);
    } else if (...) {
        ...
    }
}

For this task, we only need a deprecation warning. When we get around to dropping support for master, the code won't have to worry about it at all -- an XSL transform will map master to clone before the code ever sees it.