Dealing with Contract Keys in a typed manner is very difficult at the moment:

A contract key can be a variety of different types (anything Value.class returns). This leads to the actual java type being a simple String, a Daml Tuple.class or full classes generated by codegen.

This leads to complex type handling on a per Template basis having to understand what Value will be returned and handle it.

It would be much easier if ContractKey classes were always generated instead of the "sometimes yes and sometimes no".

What is the solution you would propose?

as described here: https://discuss.daml.com/t/input-limit-on-template-key/3029/3?u=stephenott there are multiple ways a template key could be established in the daml template.

It would be nice if the codegen generated a contract key class for each Template's contract key so we can work in a typed manner that is closer to the template instead of working with the complex variation that is returned by the DamlRecord.

Even if a contract key was a single field such as a string it would still be wrapped into the generated class representing the ContractKey for the specific template.

Further this would simplify dealing with TransactionTree results where the contractKey is being returned outside of the contract class that was generated (because contractKey is a field in CreatedEvent vs where a Template's inner "Contract" class has a typed contractKey field)