That's exactly the case 
All these things you mention are internals that predate Swift Concurrency, and we are in the process of porting them over to the language provided (distributed) actors.
Current state of the Distributed Actors (Cluster) internals
Short version: What you are looking at is runtime internals long predating Swift Concurrency, and effectively is a complete "library only" actor runtime; We will be removing most of these internals, as they have either become obsolete in face of the runtime now offered by the Concurrency library, or they are being replaced by the work in progress distributed actor feature.
So, why did we share this library early, while there still are those pieces of the old infrastructure in there...?
After careful consideration we decided to release this project as work-in-progress to help the public review process of the distributed actor feature (as we mention in the annoucement blog). During the initial pitch of the distributed actor language feature it became clear to us that it will be very hard to explain and justify exact details of the language design, without having a reference implementation associated with it, so we're able to explain exactly why and how those features are used.
Remember that the language feature basically "does nothing", it just is a bunch of hooks for runtimes such as this one to do their thing. So it can be pretty hard to grasp exactly how it's supposed to work, without having a reference implementation at hand.
Thankfully, we had this runtime since quite a while, and it is a pretty complete distributed actor system - only pending a full "rebase" onto the language features, some of which are still evolving. Since this project is server-side focused, and does not carry any specific internal or product related secrets, we were able to open source early, allowing the community to participate in the design and evolution more actively -- avoiding weird situations where we would have to push against Swift Evolution feedback, without being able to specifically articulate why exactly. With this lib being open, we can point at specific implementations and how the language feature is used "in reality" 
Summary
So, should you care about: _Behavior, _ActorRef, shells etc...? Not really, they are both internal and going away as soon as we're able to express everything we need using the Swift provided language features
Having that said, it is an interesting case study how actors would have looked like if they were just a library. We did multiple implementation attempts, from functional Behaviors (the most true to the actor model described in computer science literature, however also quite verbose), to actors driven by source generation. I want to mention this because during the feature review a few times it was mentioned that we could "just" implement distributed actors as a library, and the reality is that we tried, many times, and the results were not satisfactory, leading to the current distributed actor Swift Evolution proposals
We can nevertheless discuss the internal design, if you're curious, I'll post a follow up post answering your questions right away, but for anyone else reading -- none of these matter in order to understand or use distributed actors as we are proposing their way forward