(Maven dist build: build the src artifact from the dist too.)
(Manual: moving getTemplate down where it belongs in the example.)
(Just some comments)
Overloaded methods: Started reading source code => Comments on suspected issues, renamings and trivial refactorings to make the code more understandable. No behavior was changed yet.
Updates version
(needless import)
New BeansWrapper, DefaultObjectWrapper and SimpleObjectWrapper constructor that takes a Version incompatibleImprovements argument. This has the same role as the incompatible_improvements setting of the Configuration, but it applies to the ObjectWrapper instead. (As ObjectWrapper objects are often shared among multiple Configuration-s, they can't use that setting of the Configuration.)
Fixing bug where in some rare cases overloaded varargs methods used less specific type hinting than possible with our current approach. For example, for m(File, String...) and m(String...), sometimes (unpredictably, depending on in what order the Java API has returned the methods) it has unwrapped arguments with the hints [Object, Object, Object, etc.] instead of with

[Object, String, String, ...].
(Just some javadoc/comment typos and some tab-to-space conversion.)
Refactoring to avoid the somewhat expensive getSignature(member) calls when searching the best matching overloaded method (and elsewhere too), also to get rid of Map<Constructor|Method, Class[]> signatures and thus also the Map lookups in it.
Some cleanup-refactoring in the overloaded methods code... got rid of those Object return values everywhere at this point.
Amend to: Some cleanup-refactoring in the overloaded methods code... got rid of those Object return values everywhere at this point.
(Some more refactoring/cleanup...)
Fixing bug: null argument values has only matched overloaded methods where the corresponding parameter had Object type, not a subclass of it. Also did some code cleanup along the way.
Bugfix (active with new BeansWrapper(new Version(2, 3, 21))): In many cases, less specific hint class was used for unwrapping than that was theoretically possible within the limitations of the applied hint generation algorithm. (The unwrapping hint has influence when there's an ambiguity regarding how to create a Java object form an FTL value. In the vast majority of the cases, a too generic hint has no effect.)

The limitation of the applied algorithm is that, a single common unwrapping hint class is chosen for a given argument position shared by the overloads that has the same number of parameters. The issue with the too generic hints had several instances:

(a) When the most specific common class/interface of two same-position parameter types were searched, if there was multiple common class/interfaces that had no relationship (this is always at most one class and one or more unrelated interfaces), due to the ambiguity it has felt back to using Object as the unwrapping hint. Now if there's a non-Object class among them in such case, it will be chosen as the hint. Otherwise if only a single interface remains by removing Cloneable, Serializable, and Comparable (in that order), that will be chosen. Only then it falls back to Object.

(b) The common most specific class of a primitive type and the corresponding wrapper class was sometimes Object instead of the wrapper class. This depended on Java's the internal ordering of the methods, and so were quite unpredictable.

(c) The common superclass of a numerical primitive value and a numerical non-primitive value was always Object, now if the are primitive-boxing class pair, then it's the boxing class, otherwise it's Number.

(d) If the varags parameter position was not the same in all the overloaded varargs methods, sometimes some varargs arguments where unwrapped with too generic hints. When this happened was unpredictable as it depended on the internal method ordering.)
(Minor comment and manual typos/improvements...)
Overloaded methods bugfix: Ambiguity is now resolved in some cases where earlier it was an error. Ambiguities was and are resolved by selecting the compatible methods then choosing the one with the most specific parameter types among them. How the specificity of the parameter types is calculated was extended:

- When comparing the specificity of two parameters types at the same parameter position: The algorithm now considers a primitive type as more specific that its corresponding boxing class. Also, the now it considers widening conversion from primitive numerical types to numerical classes, and from numerical class types to other numerical class types, and if the target is wider than the source, then the source is considered to be more specific. (Earlier this has only worked among two primitive types). Furthermore, it considers any primitive numerical type as more specific than Number.

- When comparing the overall specificity of two parameter lists: Earlier the more specific parameter list was the one that had some parameters that won in specificity, and if both had such parameters then it was an ambiguity. This rule changes in that now parameter specificity wins has a score, and the parameter list that contains the parameter with the highest score wins. The scores from lowest to highest: primitive wins over boxing type, narrower numerical type wins over wider numerical type, and subclass wins over super-class.
Add some test cases to demonstrate further bugs to fix, also some that covers some earlier fixes more.
Closing the Null.class inside ClassString, never to get out from there. Some trivial cleanup.
Fixed FTL stack trace glitch where if an #if had and #else or #elseif, the #if/#else/#elseif wasn't hidden in the FTL stack trace when the error was inside its nested block.