It’s great to hear the pain points that exist in Kotlin, especially when examples are provided! But I do think the method of this message obscures the value of providing feedback with a personal tone and a focus on big picture language design instead of on specific pain points, use-cases, or possible improvements.
I do think that your perspective is relevant, which is why it would be beneficial to the language if you used your experience with Kotlin to contribute with use-cases and feedback as you are hoping to do now.
some meta comments 
Saying this paints things as one broad stroke, and when I read this I hear it in a harsher tone than it was likely intended to be. Reading the post makes me feel a hint of ad hominem that may take away from the feedback you hope to provide.
Your background is nice but it’s less important than the investigation into the details so I’m glad you provided an example
the feedback
From a quick pass, I’d break out the following specific pain points:
- Confusing or inconsistent converting between types
- Shifting behavior (that I can’t define right now but I did find in the Kotlin course in Jetbrains Academy)
- Lack of a standard library comparison with
==for comparing Ubyte with UInt - Experimental status of arrays and value types (or other native types)
- ? An issue I didn’t understand with ubyte array xor’ed with another ubyte array ?
I’d also separately start to talk about the pain of feeling the language choices have not prioritized these issues and a few assumptions about why that is the case and the motives of the others. I’d consider a lot of this to be distracting from the effort to identify and understand problems–it’s more valuable to stick to concrete specifics
I can’t speak to all of the points but here are a few quick comments:
@arkanovicz had a good example for #1. I would maybe add conversion is complex. See this other conversion example of complexity. It often feels like there is an obvious way to do conversions when in reality it’s a more complex problem in many cases.
Thankfully, Kotlin enables us to reinvent these “language level” features as libraries!
Kotlin has the tools to allow you to create powerful library-based tools (see for example, GitHub - kunalsheth/units-of-measure: Type-safe dimensional analysis and unit conversion in Kotlin.).
A few enhancements that may be relevant:
Value classes is one of the enhancements that will even further enable you to tune Kotlin using standard language features by defining your own “primitives”, just as the unsigned numbers are defined. Especially valuable for number stuff
Context clauses will also allow for more powerful extension of existing types greater than the current extension function ability.
Another note on bitwise operations from my experience: The JetBrains Academy course in Kotlin spends a maaaaasive amount of time doing bit and byte stuff… I was pretty surprised that it was so heavily focused on. It’s definitely beginner material but the focus is there from the start for performing bit operations and working with bytes–at least it is there way more than I expected.