if I’m being honest, this is a very good change since it helps reduce imports (removing the need for openfl.utils.Assets) and makes code cleaner in general, so I like this so far

There is some problem with async text/binary assets. They are not cached by lime. This can lead to inconsistencies between html5 and sys targets: a user expects to get the cached asset with FlxG.assets.getText('atlas.json', true) but instead receives error asset "atlas.json" exists, but only asynchronously.

// Project.xml
<assets path="assets" embed="false" preload="false"/>

// Main.hx
openfl.Assets.loadText(AssetPaths.atlas__json).onComplete(json -> {
    // error on html5 "asset "atlas.json" exists, but only asynchronously"
    trace(openfl.Assets.getText(AssetPaths.atlas__json));
});

Possible solutions:

• use the same cache rules for text/binary as lime does - no useCache param for getText() getJson() etc
• flixel maintains its own text/binary cache for non sys targets (sys targets treat any asset as local, so such asset is read from file system when it's not cached)
• make Lime team to implement cache for text/binary

There is some problem with async text/binary assets. They are not cached by lime.

The purpose of this PR is to add the ability to override the functionality of how flixel loads assets from string paths, I created FlxG.assets as an easy place to find this feature (and perhaps various other asset related features).

What you're describing seems like a separate feature related to flixel's asset system, which may or may not be implemented regardless of whether this PR is merged. Do you agree? If so, I would make a new issue, if not, I may need you to elaborate, cuz I'm not seeing the relevance

I may need you to elaborate

At brief look this pr api suggest text/binary assets can be cached, but in fact - they are not. May be it should be more clear in doc about that.

a separate feature related to flixel's asset system, which may or may not be implemented regardless of whether this PR is merged. Do you agree?

I am kinda agree. This pr fits for text/binary asset cache feature in a way that without new asset front-end it's hard to implement the feature.