As i understand it, you dont use seperate threads, they just work as if they were seperate threads, correct?
If you had seperate threads for systems, you would still need to watch out for locks on data. In this case, the input handling is either writing (just set the acceleration vector) or reading and writing (changing the velocity vector). In this case, another system should neither read nor write on those data, as it could read data that are in the state of change. That could lead to unintended consequences.
In a concurrent ECS, you still need to think of the order of systems to call. Rendering your character in an jump or fall animation, while clearly still on the ground would be an obviously bad idea. Collision detection before moving could result in the player stuck in a wall.
On top of that, some systems are get called more often than others. If your game is set to 60 fps for rendering, that does not mean that some other systems like player input are also working only 60 times per second.
So, what you should think of is what in what order are your systems called? If you detect the collisions first, but then override your movement with the input, that would be useless.
Second, what does your input handler write in the transform component? If it is a new velocity vector then that vector will get used in the collision detection (and in case of a collisiion changed). if Input Handler gets called more often than the collision detection, you collision detection might not work.
So in short, if you call your systems concurrently (start a system after the system before finished) there should not be a problem, if your data is organized correctly and systems get called the correct amount of times in relation to other dependent systems.