I'm not sure what the benefit of a change that goes from three blit methods to three blit methods is. It seems like we'd be doing a lot of work for not a lot of improvement.

The benefits would be twofold : one, clarify what function does what, two, add the position behavior to the public method.
Plus, absolute_blit and integer_blit would only be kept for compatibility for code written without caring for types, and would not be used in new internal code.

What's more, I suspect the functions called by these blit methods don't actually care about the type of the values, and only consider them as absolute number of pixels. If that's confirmed, then all three existing methods actually do the same thing and could be merged into one raw_blit passing the values without conversion. Another creator-public blit that would implement the position mechanism could then be added aside it, and we would end up with only two methods.

The proposed changes add additional lookups, conditionals and/or frames to the stack for both blit and subpixel_blit. Given the frequency with which these methods are called the small amount of existing code duplication seems much preferable.

The second version with raw_blit would actually quicken the code for a lot of uses (if not all) where the type of pos doesn't matter - and look it up, very often blit is called with literal (0, 0). Calling absolute on the pos when needed then calling raw_blit, instead of calling absolute_blit, would be equivalent in terms of call time.
In that case, nested calls would be reserved for internal uses where we don't bother to figure out the types (but that can be phased out), and only if it turns out that the type of the values actually matter, which I do't think it does. The creator-public method implements more features, so it makes sense for it to be a bit slower.

I think we're a bit in the fog until we know for sure whether passing an int or a float/absolute with an integer value actually makes any difference.