Instances are required for server authority so they can be predicted! Both the server and client need access to the instance. If you had binded inputs with a service like ContextActionService, only the client would be able to access it.

cross-script access to the same inputs is a big factor imo - that way eg. you can have both your death script and your cutscene script disable movement

I also have some other small concerns with the new Input Action PlayerScripts but they don’t require an entire bug report dedicated to them.
Is there anywhere appropriate I could forward all these too? Any chance we could get an engineer to go over a lot of these outdated PlayerScripts and optimize plus fix them up heavily? For reference, most of the experiences I work on rewrite the default PlayerScripts just to optimize and fix them up, and then update them whenever a new feature or update to the PlayerScripts roll out.

Examples of the small issues I’ve noticed:

1. PlayerScripts not using the new Raycast API’s ExcludeInstances and IncludeInstances for better performant raycasts.
2. PlayerScripts not using :QueryDescendants, Vector2.zero, Vector3.zero, Vector3.one, Vector3.yAxis, etc over manually creating Vector3s for small performance gains and not using the new +=, /=, *= keywords.
3. Multitude of locations within PlayerScripts accessing game.Workspace or game:GetService("Workspace") over workspace for consistency sake.
4. Multitude of locations within PlayerScripts calling deprecated :connect and :disconnect, :GetPrimaryPartCFrame, CFrame:vectorToWorldSpace and more.
5. Multitude of locations within PlayerScripts accessing deprecated properties such as CFrame.p, Vector3/CFrame.y, Vector3/CFrame.x, Vector3/CFrame.z, BasePart.Velocity, BasePart.RotVelocity , Camera.CoordinateFrame and more.
6. FlagUtil not being used for unified grabbing of FFlags in,

StarterPlayer.PlayerModule.CameraModule.TransparencyController
StarterPlayer.PlayerModule.CameraModule.VRBaseCamera
StarterPlayer.PlayerModule.CameraModule.VRVehicleCamera
StarterPlayer.PlayerModule.ControlModule.ClickToMoveController (Despite being referenced and used, there's a few parts that call `IsUserFeatureEnabled` without using the FlagUtil function)

And just general bad or old code that isn’t really efficient or optimized.

There’s no difference between Vector3.new(0,0,0) and Vector3.zero, they both compile to a vector literal in luau. Although Vector2s don’t because they’re userdata.
Although it should be using the vector library where possible, as its an easy way to get extra performance with code that uses vectors. As the methods on the vector library are fastcalled.

Big fan of SCP roleplay, and obviously not Roblox staff, but no, its not intended. It’s most likely a conflict with another script or a conflict with authority. It’s really new so there are probably conflicts they havent resolved

These being instances does seem to be the better option to me, primarily for clarity with server authority. Some of its benefits come down to personal preference, but I do find setting up inputs where it works to be a lot easier with this system as well. It also comes with the added benefit of input settings being entirely separate from our scripts, which is another part I like about it.

You should be able to listen to the input under the inputs folder with the new player scripts, right? I haven’t checked how it’s done yet, but I assume the mobile joystick code is manually firing the input every frame like the scripts do with the camera to send the camera look direction to the server.

Unless I’m mistaken, hardcoding it is the only way- which kind of defeats the purpose of IAS, no?

Of course its possible, but novice scripters may as well be incapable of doing so regardless, due to how tedious it is. If IAS is meant to mix inputs it might as well support mobile inputs similarly to how thumbstick enums are mapped, otherwise developers would be subjected to fixing bugs every time player scripts are updated. Its also just not very obvious how to achieve that, there aren’t many forum posts covering the joystick- and none for mapping it to IAS, sadly most people solely rely on Humanoid.MoveDirection (which should not be used for actions in games such as steering vehicles or piloting aircraft).

That being said…
Treating the mobile joystick just like console thumbsticks requires you to match cardinal direction angles.

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local RunService = game:GetService("RunService")
local StarterPlayer = game:GetService("StarterPlayer")
local Players = game:GetService("Players")
local Player = Players.LocalPlayer
local TouchUI = Player.PlayerGui:WaitForChild("TouchGui", math.huge) -- yields if not mobile

-- Our personal Input Actions meant to bind thumbstick and joystick direction alike
local Keybinds = ReplicatedStorage:WaitForChild("Keybinds") :: InputContext
	local Forward = Keybinds:WaitForChild("Forward") :: InputAction
	local Backward = Keybinds:WaitForChild("Backward") :: InputAction
	local Left = Keybinds:WaitForChild("Left") :: InputAction
	local Right = Keybinds:WaitForChild("Right") :: InputAction

local Controls = StarterPlayer:WaitForChild("PlayerModule")
	local MoveAction = Controls.InputContexts.CharacterContext.MoveAction :: InputAction

local Angle = 0 -- 0 = cardinal only, 45 = 8 equal sectors, 90 = heavy diagonal mixing

local function angle(v)
	local a = math.deg(math.atan2(v.X, v.Y))
	if a < 0 then a += 360 end
	return a
end

local function range(a, center, halfSize)
	local diff = math.abs(((a - center + 540) % 360) - 180)
	return diff <= halfSize
end

local function Components(name)
	if name == "Forward" then return {"Forward"} end
	if name == "Backward" then return {"Backward"} end
	if name == "Left" then return {"Left"} end
	if name == "Right" then return {"Right"} end

	if name == "ForwardRight" then return {"Forward", "Right"} end
	if name == "ForwardLeft" then return {"Forward", "Left"} end
	if name == "BackwardRight" then return {"Backward", "Right"} end
	if name == "BackwardLeft" then return {"Backward", "Left"} end
end

RunService:BindToRenderStep("DirectionalInput", Enum.RenderPriority.Input.Value, function()
	local move = MoveAction:GetState()
	if move.Magnitude == 0 then 
		if Forward:GetState() ~= false then Forward:Fire(false) end
		if Backward:GetState() ~= false then Backward:Fire(false) end
		if Left:GetState() ~= false then Left:Fire(false) end
		if Right:GetState() ~= false then Right:Fire(false) end
	return end
	move = move.Unit
	
	local degrees = angle(move)
	local zones = {
		["Forward"] = 0, ["ForwardRight"] = 45, ["Right"] = 90, ["BackwardRight"] = 135,
		["Backward"] = 180, ["BackwardLeft"] = 225, ["Left"] = 270, ["ForwardLeft"] = 315
	}

	local diagonal, cardinal = Angle, (360 - (4 * Angle)) / 4
	local active = { Forward = false, Backward = false, Left = false, Right = false }
	for name, center in zones do
		local isDiagonal = (name == "ForwardRight" or name == "ForwardLeft" or name == "BackwardRight" or name == "BackwardLeft")
		local size = isDiagonal and (diagonal / 2) or (cardinal / 2)

		if range(degrees, center, size) then local components = Components(name)
			for _, dir in components do active[dir] = true end
		end
	end
	
	if Forward:GetState() ~= active.Forward then Forward:Fire(active.Forward) end
	if Backward:GetState() ~= active.Backward then Backward:Fire(active.Backward) end
	if Left:GetState() ~= active.Left then Left:Fire(active.Left) end
	if Right:GetState() ~= active.Right then Right:Fire(active.Right) end
end)

Most games attempt to treat mobile joysticks and console thumbsticks as one in the same. I simply believe this is too tumultuous for those who are new to studio to attempt to do when mapping the joystick to input actions or mirroring the behavior of thumbstick direction enums.

If someone knows what stand practice is for mapping the mobile joystick to IAS please let me know.

This is definitely an issue. It would be nice if there were a property of Direction2D which would make Roblox’s player scripts also fire the input with the mobile joystick. Right now the only thing you could really do is make your Direction2D mirror Roblox’s (LocalPlayer > InputContexts > CharacterContext > MoveAction) using a script, which as you said is going against the expectations of how IAS is set up.

ContextActionService can probably go, but the new system is more for general inputs, UserInputService would still provide you with low level information and will probably remain, but you can at least move on from it more than likely.

the new PlayerModule is now found in StarterPlayer