(Edit: I stand corrected, Perl does! threads::shared is a core perl module)

Now, you say it would give perl more power for multi-processing if Perl did have this, but you need to make a stronger argument to convince us. To start with, many of us do not even use perl threads in the first place, and may even disable the feature in our perl interpreter to make it run faster. This is not because we aren't familiar with the idea (I did a lot of Java back in college) but because we have found other ways to solve our problems using perl.

For shared structured data, most of us use a database. There are many databases to choose from, too. You can of course run Postgres and create a table with a 'json' column, and write arbitrary data to it, or you can use a database-file like LMDB_File or SDBM, SQLite etc. In these cases perl memory-maps the file data and serializes and deserializes on each read/write. If you need locking, you can implement it with flock.

For shared flat data, you can just File::Map it into each process or thread, and have high-speed un-synchronized access. This is most useful with large static data that doesn't need synchronized anyway.

For the few types of problems where people really do want this, they probably also want more speed than plain perl. The XS modules give you a lot of speed in addition to extra threading features.

While it used to be common for people to implement high-speed transactional behavior inside of a single process, I just haven't needed to do that in the last 15 years that I've been using perl. Almost every modern application needs the potential to scale up beyond one process on one host, so I pretty much start every project assuming I will use some type of database.

Maybe you can describe the problem you're trying to solve that would benefit from tight single-process relay of data structures between threads?