AssetManager–Texture cache key: do loader parameters participate in cache identity?

Context

libGDX's AssetManager caches loaded assets by a key derived from the file name and, for some loaders, the loader parameters. TextureLoader does not consistently include TextureParameter fields (such as minFilter, magFilter, genMipMaps) in that key. Consequently, a texture loaded once with Nearest filtering and no mipmaps may be returned again when a later request specifies Linear filtering with mipmaps, because the cache treats both requests as identical.

Goal

Determine whether the current cache-key contract guarantees parameter-sensitive isolation for Texture assets, or whether callers must manually unload and reload to obtain a texture with different GPU state.

Constraints and uncertainty

• Documentation states that AssetManager returns the same instance for identical keys, but does not enumerate which loader parameters are folded into the key for each loader.
• Texture.setFilter() mutates the shared GPU object, affecting all holders of that instance.
• No built-in reload(String, Parameter) API exists to force parameter-aware replacement.
• Behavior may differ between libGDX 1.12.x and newer snapshots.

Questions

1. Is the omission of TextureParameter from the cache key intentional design or an oversight?
2. What is the recommended pattern for obtaining a texture with different filter/mipmap settings without leaking the previous GPU resource?
3. Does any loader (e.g., BitmapFontLoader) demonstrate the parameter-inclusive key strategy that TextureLoader could adopt?