Code-driven configuration of property dialogs uses constructs like the following:

cfg.fields.multi("fieldname")
		.label("Field label")
		.transformerClass(MultiValueChildNodeTransformer.class)
		.field(cfg.fields.link("link")));

The problem is that transformers can only be given as a class here rather than an actual transformer object.
This makes the code rather unwieldy in some contexts (e.g. you can't use an anonymous class there) and, what's even worse, several very useful features are totally impossible, such as giving special constructor parameters or using closures.

What I'd love to see (instead or as an addition) is the following overload:

AbstractFieldBuilder#transformer(Transformer transformer)

.

Wouldn't you agree that this is a lot better to read and to use anyway? Why choose the complicated overload mentioned above when you can have this simple one?

A similar scenario exists with validators. The two currently existing overloads are

AbstractFieldBuilder#validator(ConfiguredFieldValidatorDefinition validatorDefinition)
AbstractFieldBuilder#validator(GenericValidatorBuilder validatorBuilder)

These overload have roughly the same problems as the transformers, they're totally unwieldy or even completely useless in many cases because of their inherent limitations. It would be a lot better if you could just add an overload that accepts an instance of a simple Validator interface that might look like this:

interface Validator
{
   public void validate(FormField field) throws ValidationException;
}

Another issue in the very same line of argument is

ConfiguredFieldDefinition#setConverterClass(Class<? extends Converter<?, ?>> converterClass)

.
This again accepts only a class. Couldn't there also be an overload that is a lot simpler and straight-forward and just reads:

ConfiguredFieldDefinition#setConverter(Converter<?, ?> converter)

.

The last aspect I'd like to point out is that the issue was well done in the case of

LinkFieldBuilder#identifierToPathConverter(IdentifierToPathConverter identifierToPathConverter)

. Interestingly this method does even demand an IdentifierToPathConverter object in every case (no class allowed), even though this means something like typing

.identifierToPathConverter(new BaseIdentifierToPathConverter())

most of the time, which looks a little funnier than using

BaseIdentifierToPathConverter.class

instead.
Nevertheless I really appreciate this approach because it offers so much more flexibility. I would highly appreciate if the same amount of flexibility could be added to other field configuration.

Adding these overloads wouldn't even mean a lot of work and effort from your end imho. It would just mean adding a few simple lines to the Builders, the Definitions, and the Factories, and you'd be done. It's neither hard nor complex, but not doing it occasionally makes things hard and complex for us developers using Magnolia.
So please add this great extension to Magnolia's usability and flexibility.