Wanted to give you all an update on when this would go live. The issue mentioned before has now been resolved and while we cannot give you a specific date we are looking at enabling this very soon so keep an eye out for the announcement.
Thank you all for taking the time to try this out before we release it!
ModuleScripts run on the script they were imported on, so no.
Will RunContext be able to be run in Live Games once this features comes out of beta?
The meaning of beta is that it doesn’t run in live games 
.
Both of you are 100% correct. It will be available after RunContext is released (I believe it was stated earlier in this thread).
I encountered a very strange bug when using this thing.
So for some reason scripts with Client RunContext recieve RemoteEvents from the server twice. However this does not accur in LocalScripts. I cannot post this in #bug-reports, so I am posting this here.
(my post if anyone needs - RemoteEvent is being recieved twice for some reason - #10 by AlternativeOrNot)
Quick question, where exactly was this script located within your game?
It was located in the StarterGui.
This is in fact expected behaviour.
Your script wasn’t receiving the event twice, it was in fact being cloned into the Player’s GUI. Since StarterGui also replicates to the player, there were two active instances of the script.
Thanks. But why isn’t this a thing for LocalScript though?
Interesting question!
Since LocalScripts were introduced, they only ran in specific places. Meaning that if they were parented to anything else; even if the client could see them, they would not run it. You can find an up-to-date list of these places here: LocalScript | Roblox Creator Documentation
There are many reasons behind keeping this behaviour. For example, most tools with scripts in them would break completely as the LocalScript in them only ran for the current user.
To allow for a better code structure, Roblox needs to give a tool for developers to control for themselves where scripts run. RunContext is that answer. The consequence of this is that you as a developer need to handle whether the script runs or not by yourself. You could, for example (although I don’t recommend this as LocalScripts are not being deprecated at this time and perfectly suit your use case), add this to the start of your RunContext Client script:
if not script:FindFirstAncestorWhichIsA("PlayerGui") then return end
This should fix your particular issue, as it would prevent the script from running outside of a player’s GUI, when cloned.
Shouldn’t it be
if script:FindFirstAncestorWhichIsA("PlayerGui") then return end
?
Nevermind i just re-read the post.
If you need to do this, try creating a moduleScript and then having a Server Script and a Local Script that require it contained inside. For example:
Has a new issue arrisen? Have been looking forward to this so I can use it live.
It’s been live since yesterday morning. There is the possibility that it could be turned back off though.
We enabled this quietly on Friday so you will now be able to use it in your experiences!
Yes! Thanks! Luckily some of us might have noticed this post, why quietly though? The roblox studio notifications channel is really useful for us the developers 
By enabling things a few days before announcing them we have an opportunity to monitor them before they are adopted by developers.
Noticed this being enabled, very helpful for saving server resources for some things in my game. Glad this is being released!
For those saying this has no use case, you can now place a localscript inside of an instance, so that when that instance is deleted, the localscript is deleted too.
I’m actually using this behaviour in an ECS I’m developing to make object oriented programming more powerful and reliable. This change just allowed me to have oop instances automatically clean up their connections.
Yes, I could have coded this with tags, but this saved me a ton of code, and made everything surprisingly more organized, as the functionality tied to the entity can now be found as a child of the entity, which is easily accessible, instead of having them all crammed up in one space.
And no, I can’t just use a metatable, those don’t clean up automatically like a deleted script does, I don’t want my programmers to have to take care of complex memory leaks.