I think what you suggest is fine for Accountancy. UserAccount is deliberately not designed for extension but delegation: a customer has an account, it is not one. All examples of additional data that folks intended to add to the UserAccount type have been better off in a custom domain type that's then holding a reference to the UserAccount.

Generally speaking, we shouldn't equate "extensibility" with "possible to inherit from" or "easy to inherit from". Extensibility is more often achieved by using delegation or exposing dedicated strategy interfaces so that custom implementations can be used. See LineItemFilter in the inventory module for example. Adding extensibility to the mix in the way suggested adds significant complexity for students that want to use the types as is as they need to understand why they'd have to declare Accountancy<AccountancyEntry> everywhere, which looks like stating the obvious in the first place.

I guess we even have to carefully test this for Accountancy as all other abstractions that use that pattern assume that only a single extension type is used. E.g. if you customize Order to MyOrder, using OrderManagement<MyOrder> only work if all instances added are MyOrder instances. For Accountancy, we already persist ProductPaymentEntry instances. So if a user created CustomAccountancyEntry and used Accountancy<CustomAccountancyEntry>, the call to AccountancyEntryRepository.findByDateBetween(…) would return both the ProductPaymentEntry and CustomAccountancyEntry with the former resulting in ClassCastExceptions as they don't implement CustomAccountancyEntry.