Thanks, Sam. The articles largely align with my existing conception, hence my raising the question. The first article also reflects my concerns about the pooling of FlxPoints and FlxRects.

I would argue that consistency for consistency's sake is not such a good thing. If there are costs to something, even if the costs is merely a small redundant effort, it seems better that practices should change, than for "consistency" to allow the practices to persist. Having a consistent API is important because it makes the API easier to follow for users. However, trying to be consistent between cohesive implementations doesn't really have any benefit that I can see, whereas it can be costly to performance, ease of maintenance, or perhaps just effort to implement or learn. The explicit nulling seems to me to impact initial implementation effort, but also ease of maintenance.

I've noticed a few places in HaxeFlixel that seem to require effort for something redundant, or in some cases have potential performance or maintenance drawbacks, and I can't see any reason for them other than consistency, or at least, they persist for the sake of consistency. There are a few things that have persisted from as3 flixel which perhaps never would have existed there were it not for certain as3 deficiencies (that haxe does not have). There are a few style decisions which seem to lack motivation, but which persist in the name of consistency.

I'm wondering if a review of such things might be possible at some point? I'm particularly keen to see that as3 Flixel does not hold back HaxeFlixel.