Difference between facade and orchestrator in the context of microservices

Facade tells me it’s a simplified interface that abstracts more complicated interfaces.

Orchestrator tells me it’s telling things what to do and expecting those things to do it.

Technically both are true. But isn’t the first one the point you’re trying to make?

However, the better name tells me what it does. Not how it does it.

Is this an example of facade pattern or microservice orchestrator pattern?

It is probably both, patterns are not mutually exclusive. But the name you pick for C should express the client-facing abstraction. To my understanding, "Orchestrator" expresses more what C does internally, and "Facade" more how the interface looks like for the client.

Hence in case it is transparent for the client that C is just a simplified interface to A and B, I guess the name "XYZfacade" will fit better. However, in case C now fulfills a purpose on its own, and in case it uses A and B internally for this purpose is just an implementation detail, I would prefer a name which expresses the purpose exclusively, without any suffix like "facade" or "orchestrator". Why not just call it "XYZ" (- not literally - assume "XYZ" describes the specific topic C deals with)?

At work I have written an Edifact parsing and validation framework that has a bunch of classes you could use to refine how the parser behaves, what it considers as valid Edifact and what it sees as error. The setup here could potentially involve like 8 classes. That framework though also provides a single EdifactReader class that acts as a facade to hide away the complexity of configuring the parser and what not. This class will probably solve 90-95% of all Edifact parsing and validation cases users might have by configuring the most common settings for you and provide a simple List<RawSegments> segments = read(InputStream), EdifactInterchange interchange = validate(List<RawSegments>) and List<EdifactValidationIssue> issues = getValidationIssues() API interface for your convenience. The focus here is clearly on simplifying the usage of the Edifact parser and less on the orchestration itself. Hence this is a perfect example, IMO, for a facade use case.

An application I currently develop that takes care of syncing the state of various external systems like Notion based feature requests for internal projects, FeatureBase posts that express feature requests made by various departments and then Gitlab issues or epics where we developers maintain our tasks on various boards and the like, uses an orchestrator pattern to basically call the various data synchronization tasks that need to be performed between those systems. The focus here is clearly not on simplifying the API for users but to make the synchronization process more graspable and cleaner to the reader of the code and have a central location that is responsible to call the appropriate synchronization processes based on the state of those system API responses.

While both patterns clearly have some overlap, I think the focus on what the facade or what the orchestrator try to achieve are very different in nature. Given the problem statement in the OP I'd say it sounds more like an orchestration pattern to me than a real facade where you just try to simplify the API for the end users. But I like Doc Browns answer that leaving out facade or orchestrator from the name and name it such that is express what it actually does is probably the better option. You are of course free to document that class or system and explain that to a client it is more of a facade but internally it'll orchestrate processes among various systems for the convenience of simpler client interactions.