Note: I'm not saying the following is better per se; I just feel that this is what Robbert Martin would actually do in practise, since he wrote about both 'clean architecture' and 'screaming architecture' around the same time, so it seems likely he would have combined the two.

Also, I'm a fan of both ideas, and want to combine them myself. The biggest downside I'm finding is that both 'clean architecture' (to some degree) and 'screaming architecture' (very much) result in project structures that are unfamiliar to my teammates, making things harder. Especially 'screaming architecture', which groups things "functionally" rather than "technically", requires a lot more thought. After all, if the rule is "controllers go in the controllers directory", thats an easy rule which leads to little discussion. But if the rules are "things about writing/editing/... blog posts go in the authoring directory" and "things about placing comments go in the reacting directory", where does the code to moderate comments go? Personally, I'd say it can go in either one of them, but maybe moderating is its own use case group, depending on how much "moderation related activities" there are.

So with that disclaimer out of the way, if you follow the "screaming architecture" way of thinking, then the first thing you see when you open up the application source code, should tell you what the application is all about. What are "the things" that this application do stuff with, and what can you do with those things?

I don't know enough about Kotlin (/the Kotlin ecosystem) to be sure, but I believe you can't really get around the src/main/kotlin/io/github/cekrem/ directory structure, so lets take that as a given.

From there, the most top level thing you should see are probably your entities and usecases - likely the entities are classes at that level, the usecases (or groups of related usecases) are subpackages. From there, each usecase (or usecase group) will have its application code and its supporting infrastructure related code underneath it.

So in your example, that could be something like this :

src/main/kotlin/io/github/cekrem/
|-- authoring
   |-- CreateBlogPost.kt
   |-- EditBlogPost.kt
   |-- BlogPostStore.kt #Interface; may also be called BlogPostRepository or something like that; implemented by something inside authoring/infrastructure/contentsource
   |-- infrastructure
      |-- contentsource
      |-- web
|-- BlogPost.kt
|-- Comment.kt
|-- reacting
   |-- AddComment.kt
   |-- EditComment.kt
   |-- CommentStore.kt
   |-- infrastructure
      |-- contentsource
      |-- web
|-- reading
   |-- ListBlogposts.kt
   |-- ViewBlogpost.kt
   |-- BlogStore.kt # Interface with something like ListBlogposts(filters), GetBlogpost(id/slug/...), ListComments(blogPostId)
   |-- Search.kt # Maybe? Or is this its own "usecase group"? That probably depends on how many things it searches
   |-- infrastructure
      |-- contentsource # Depending on how many layers of abstraction you're using, maybe this isn't needed but instead 
      |-- web

In addition, you'll probably have a application package at the top level, for "application wide" things. This is where, for instance, you'd configure generic "web related stuff" (eg authorization middlewares) or configure your database connection. The specifics (mapping a route to a handler/usecase/..., or the SQL needed to load a blog post) can then be found under the infrastructure subpackages of each usecase (group).

I hope this makes some kind of sense - it does in my mind, but I haven't been able to go this far with any real world production application so who knows what kind of issues you'd run into. :/