It may be a bad thing for some projects, but creating any fork causes a more major problem for later maintenance of bugs that are found extremely late (including security bugs) because the fork is insufficiently reviewed and tested and was created in a limited context.
Stadnard libraries make a lot of efforts to document their API, including their known "caveats" and suggesting other uses for these border cases that have already found to be problematic.
In other words, with standard libraries you must RTFM and apply it strictly! Only if the API says that the behavior is undefined, then you can create an encapsulation layer to isolate these cases only to make sure you get the behavior you expect, then still use the standard libraries for everything else. You limit the damages ! And you have much less cases to test and support. But your application will absolutely need to use your new layer to be consistent, and not mix both (because you would risk to have BOTH the undefined behavior of the standard libary and your defined layer.
One way to do that is to well structure your project dependencies: only your layer will use the standard library and depend on it, all the rest of your application will depend only on your layer but never on the standard libary which acts as a gateway working for your application (most of the tings your layer will do will be to dedelegate the APIs of the standard libary that it does not change; this will have no performance cost for all the rest.
Languages like Lua or _javascript_ allow such isolation and delegations, but you have caveats if the standard API has "callbacks" to your application: you also need to adapt the callback factory to properly delegate most things to your application or manage them directly and hide them to the application. And you msut be careful if your applciation uses reflection to inspect the state, and some assumption may be wrong (such as comparing types and expecting an exact match: this may also require your layer to also encapsulate the reflection mechanism that your application will use).
In a good standard libary, the APIs should never change: if there's a change of behavior (or change from undefined to defined behavior) a new distinctive API should be added; as well some APIs that can be potentially dangerous or give unpredictable results in some contexts or not matching the geenral expectation should NEVER be removed, but marked as deprecated/obsolete and your developer suite should inform you when you build the project so that you can check if you need or should perform the switch to a newer API (with the risk of no longer supporting older target platforms) or keep the older (knowing that some newly discovered security may no longer have fixes developed and applied to it with a backport).
An d anyway you must read why the "'standard" library was developed, its goals, who supported it. It's up to you to see if their goals match your need and you assume the risk of maintaining alone what was really a complex and very long development with lot of tests performed on it, that you will not be able to reproduce and support alone.
Yes it is easy to create a fork; the problem is the lifecycle of the software you write immediately, and that you may soon no longer support at all because you left the project: your successors will then really hate you for not adhering to the standard, and you'll add more work for them to find a solution if your code is now broken or simply does not support the useful and common features that you blocked by deviating from the standard of your industry. Deviating from standards hwoever is valid if your project is purely personal and you don't intend to transfer it to someone else to maintain it or you are no longer working for the company that paid you to develop that specific project.
So think twice ! Any fork implies new costs or severe limitations.
