Hello! 
This is a pretty niche topic, but, I thought I’d make a little tutorial on it. Some people might find it interesting, or, useful, and, some people have just been curious about how/why I write code with WIP Roblox features.
Disclaimer!
(Don’t play with fire if you don’t want to risk getting burned!)
First of all, its really important to note something… They’re WIP for a reason! When I write code using features that have not been released, I expect that code will no longer work when the feature comes out, and, in some cases, that code might not even be possible with the final form of a feature.
Additionally, fast flags can be dangerous to mess with! You never want to work with unfinished features without having everything backed up, and, sometimes Roblox places security features behind fast flags that you don’t want to go around toggling willy nilly. There’s always a possibility of things in your save files getting messed up, or, causing issues with your account, or, maybe worse, so, don’t go around messing with everything you can find with no thoughts about it.
Though not likely for most things, you do risk causing unexpected damage.
So, with that out of the way…
Fast Flags
Roblox uses a system for quickly enabling and disabling features at any time through “Fast Flags”, aka FFlags. Roblox pushes code on Tuesdays and Thursdays each week, and, often times features exist in the engine long before they are finished. Fast flags give Roblox a way to disable problematic features without needing to wait a whole week, and, they give a way for behaviour to be toggled on and off.
Every update has change logs, and each of those change logs are automatically linked with Fast Flags. Some features Roblox pushes might not even work, and, some might require multiple flags to be enabled.
Changing fast flags
Changing fast flags can be done with a tool like Roblox Studio Mod Manager, by @Maximum_ADHD. Tools like this just put a file in your studio directory telling it what fast flags to override, and, studio loads these fast flags on its own.
You can read about RSMM and changing fast flags there.
Locating the flags for features
Find the Release Notes
First of all, an easy way to find fast flags for a feature is to use its release notes! All release notes for features have fast flags associated with them, which, helps them be tracked internally, and, helps Roblox staff how to determine what flags to change if something goes bad with a feature.
I am going to use a relatively new example, Workspace:GetServerTimeNow(). The newest place that the feature shows up is in the Release Notes for version 488: Release Notes for 488
Locating the fast flag
Locating the fast flag for this feature is pretty simple thankfully! If you right click on the text for the feature in your browser and select Inspect Element or Developer Tools, you’ll see the HTML viewer pop up:
You may already spot it, but, right above the tag that was selected you can see an attribute called fflags:
fflags="DFIntMonotonicClockDifferentialDriftCompensationHundredthsPercentage FFlagRakNetMonotonicClock DFFlagShareRakNetMonotonicClock"
These flag names aren’t usually what will show up, for example, RSMM doesn’t have flags that look like this. They’re prefixed with things like DFInt, FFlag, and DFFlag, which refers to the type of fast flag they are. Skipping past that bit, you see the names of the flags linked to that release note are MonotonicClockDifferentialDriftCompensationHundredthsPercentage, RakNetMonotonicClock, and ShareRakNetMonotonicClock, which, are what will show up in RSMM.
Figuring out which flags to enable takes a little thought, but, paying attention to the flag types, you can see there is an DFInt type, a FFlag type, and a DFFlag (dynamic fast flag), and you can likely get an idea of what they do. FFlags and DFFlags are toggleable flags, and, DFInt, is well, an integer.
As you can maybe guess, DFFlagShareRakNetMonoticClock probably enables sharing the clock time somehow, probably with the client. The long DFInt flag probably controls how aggressive the clock is sped up or slowed down by to account for ping and such, and FFlagRakNetMonotonicClock is likely the flag related to enabling the core feature.
I enabled both flags, and, then I tested to see what happens.
Testing the feature & locating other flags
Some features rely on other flags for their specific APIs, but, they might not be included in the release notes for some reason or another. Sometimes it does take a little digging, and, sometimes features just aren’t finished so the flags don’t do much anyways. There isn’t really any clean cut way to find these flags, or to tell if they’re working, but, what I always do is search through the flags a little, for example, I might search for something obvious like GetServerTimeNow in this case.
Testing the feature is pretty simple, it’s just as easy as loading up studio, and seeing if it works. If the feature doesn’t work, or gives you an error, or crashes studio, it either means you’re missing a flag, you broke something, or the feature just isn’t in a functional state.
Results
Here are the timer results of GetServerTimeNow() in Studio, running on Heartbeat:
You can see, this function currently still appears to return values in microseconds. This is a great example of things changing in development, and, if I were to write any code using this, I’d have to change it upon release!
As mentioned here, this API will eventually return seconds, not microseconds:
Should you report issues for early features?
The short answer is no, you generally shouldn’t report issues with WIP features.
Usually, Roblox drastically changes features, sometimes one time, sometimes five before it finally releases. Roblox will usually release features into beta before enabling them everywhere, and, those are the best times you should be reporting vital issues because before betas, the version of the feature you are messing with might be completely different than the one a Roblox engineer is working on at the same moment in time.
Urgent issues for released features aren’t urgent for unreleased ones.
Why would you want to use unreleased Roblox features?
Well, there are a few reasons I personally like to do this. It lets me get familiar with the feature, and, I can even write code with the feature before its even ready. This does mean I might have to wait a month before that code can ever be used while a feature is refined, and, sometimes it means I have to rewrite my code, but, sometimes it can be quite helpful, and, at the very least, its interesting.
Additionally, sometimes I find issues with a feature before it releases, but, the issue gets missed by the time it goes live. Getting to know the feature more beforehand also means getting to know its issues at that time, and, sometimes it gives me some useful insight for later.
Lastly
I really hope this is interesting or insightful, and, if you have any comments or concerns, please do let me know!