Too many "pattern suffixes" - design smell?

A good tip is: Your class public API (and that includes it's name) should reveal intention, not implementation. I (as a client) don't care whether you implemented the builder pattern or the factory pattern.

Not only the class name looks bad, it also tells nothing about what it does. It's name is based on its implementation and internal structure.

I rarely use a pattern name in a class, with the exception of (sometimes) Factories.

Edit:

Found an interesting article about naming on Coding Horror, please check it out!

I see it as a design smell - it will make me think if all those levels of abstraction are pulling enough weight.

I can't see why you wanted to name a class 'InstructionBuilderFactoryMapFactory'? Are there other kinds of factories - something that doesn't create an InstructionBuilderFactoryMap? Or are there any other kinds of InstructionBuildersFactories that it needs to be mapped?

These are the questions that you should be thinking about when you start creating classes like these. It is possible to just aggregate all those different factory factories to just a single one and then provide separate methods for creating factories. It is also possible to just put those factory-factory in a different package and give them a more succinct name. Think of alternative ways of doing this.

Lots of patterns in a class name is most definitely a smell, but a smell isn't a definite indicator. It's a signal to "stop for a minute and rethink the design". A lot of times when you sit back and think a clearer solution becomes apparent. Sometimes due to the constraints at hand (technical/time/man power/etc) means that the smell should be ignored for now.

As for the specific example, I don't think suggestions from the peanut gallery are a good idea without more context.