The current solution makes sense in my opinion. When JVM will finally support value classes on bytecode level then it would be possible to have classes with multiple properties not just one. The better option then is to stick with the current convention rather than use a one depending on the number of properties.
Current solution makes more sense to me. Representing a variable as an unboxed value is internal optimization, but conceptually it is still an instance of a class.
Yeah, from that perspective it makes sense indeed. For now I am adding the custom toString() method so the unboxed value is printed when I use the value in a String template.