I'm not sure to see the value of that, sure it looks nicer but you don't expect generated code to be nice and I see that it gonna make the code more complex.

Do you have a good use case for that ?

Apart from making the code more readable nothing more, this is more like nice to have. You can close it if you think it is not something interesting.

Another point is the Javadoc it will have nice shorter names.

I remember having started using imports and run into conflicting imports, let's keep it simple in the code.
For javadoc, we can generate links with short description like {@link long.package.MyClass #isCompatible() isCompatible} without having to use imports (I think)

We do do this in MapStruct, we generate imports for all the possible types and if there are conflicts we only create import for one type and FQN for the rest. If you want I can try it out, when I have some time. However, I don't know the code, so I can't say how complex or easy it is to do here.

Your example with the Javadoc works. However, the signature of the method still uses FQN (at least in IntelliJ), and I don't think that you can change this.

That's great if you can give it a try ! :)

The code is more complex than assertj-core and needs some refactoring love, it was been written before java 8 but I'm keen to migrate the code base to Java 8.

What you want to look at is the AssertionsEntryPointGenerator which is responsible for creating Assertions style classes and more specifically BaseAssertionGenerator#generateAssertionsEntryPointClassContent.