Slices are probably already flexible enough to use the organization strategy you suggest. This approach is conceptually similar to the Component-Based Rails Application, which orchestrates groups of unbundled Rails engines, each of which can provide any of the usual objects available in a standard Rails app (controllers, views, models, helpers, etc.).
A Gusto team member recently gave a talk at RailsConf describing how they use Packwerk to create “packs” (complete with defined, enforceable interfaces) in a Rails monolith. These packs sound very similar to the way you are suggesting to use slices in Hanami 2.
Much of what I proposed is based on ideas from DDD and Hexagonal/Clean/Onion architecture. The goal of all of these strategies is to isolate the business logic and protect it with clearly defined APIs. I feel that this can best be accomplished by sticking to the Hanami 1.x convention of placing business logic in lib, and by extending the architectural model by providing a pathway to modularization.