@Meepler1 - if you care to take a little in-depth browse of the natives list and functions, you'll find that with a little self-motivation and effort, it's not too hard to create a script (and subsequently make a dll from) that notes entities in a proximity radius or zone and if you apply this (given a suitably defined zone/radius) as a trigger to activate the existing native-based means of taking AI control of the vehicle, employ the native that enables you to trigger bringing a vehicle to a controlled halt, you're halfway there.
The trick is to make the right decision/logic tree suitable for how you want it to work. For example, if you wanted a anti-collision autobrake to avoid hitting an object that's appeared in the immediate distance ahead, you need determine if there is a nearby vehicle behind, ahead, either side (or all of these) as this and their velocity and vectors and proximity are critical key factors. These will determine whether the 'ab' system can swerve to avoid an immediate front end collision whilst trying to do an emergency or controlled stop (different severity basically) if there is insufficient survival/stopping distance. If you don't account for near proximity vehicles, you will just blindly trigger a braking action that will practically guarantee a whack up your vehicle's ass end as well as a brickwall effect impact with what's ahead if there's no adequate braking distance, and because the vehicle with 'AB' would maybe need to swerve to find more distance with a better stopping line (or to maximise ABS use), if it was done in ignorance of proximity of vehicles to the immediate and near behind/ahead front and rear, you'll just create an accident avoiding an accident - kinda defeating the object of an AB or AB/DBW collision avoidance system.

The coding bit, itself, isn't that hard - it's breaking down the functionality of the hypothetical system, finding ways to take advantage of easily available game physics data reads to act as sensor substitutes, and creating a set of rapidly processable/resolvable algorithms that derive the data you need from the available data, create subsequent data to feed the code that will eventually start triggering an actively changing series of events.

What you probably won't achieve, without going into way more involved methods (involving derived external data, or implementing it externally typically), is getting the nanosecond or microsecond accuracy timing level that microcontroller and SBC based real world systems use for processing and controlling the ancillaries - not without mimicking an emulation of this, and that's best employed through a m/c or sbc 'fake' gamepad sending subsequent controller input data to the game via the existing gamepad/controller implementation.

So whilst it's admirable to request what could be a brilliant 'add' - being a bit proactive and figuring the non-coding side out first and approaching a coder/developer to help you turn your research and findings into the addin/mod/patch goes a long way towards seeing it happen - everyone wants stuff, but few are ready to meet halfway and go do some of the hard work to assist beyond open ended concepts contributions.

You don't need to be able to code, or develop, to contribute to what you are suggesting - just make a concerted effort to interest your preferred modder/developer with a half-way involved attempt to meet halfway on the project :)