Right now my renderer is kind of hardcoded with a special path to handle planar reflective materials (those that I generate a reflection map for by rendering the scene from a mirrored camera). Right now this is only used for water surfaces.

I want to generalize my renderer so it doesn't have this special path: it just inputs a list of render items (basically, mesh + material). My question is where should the reflective texture go? Should it be part of the material: like PondWaterMaterial owns the reflection map? Then I can't share the same material among different water surfaces unless they are on the same plane (which might not be a big deal). Should the reflection map somehow be coupled with the water mesh surface?

Also, if I do have a generic rendering system that just inputs a list of "render items", do I just perform a simple query to find out which render items require a reflection map to be generated by the engine?

A 'material' isn't the only thing that needs to send data to a draw-call -- e.g. your camera is sending a view-projection matrix and your object instance is sending a world matrix. In a general renderer, both of these "data sources" could be the same level as a 'material'. I don't even really have a material class in my engine, instead I might have a variable named "material", but it's just a source of data/states that happens to contains material-type information (like a shader, some texture/cbuffer bindings, etc).

You could have a separate "planar reflection" object, which as a list of renderables which use it. It can check if any of these objects are visible to the current camera, and if so, it needs to generate it's texture. When those renderables are rendered, they can source the appropriate state (i.e. texture binding) from this object.

I think so... but you are being terribly unspecific about 'reflection
map.' So you're rendering from a mirrored camera? Well then yeah, if you
have this 'coupling' configured to support any sort of reflection
mapping technique, then I guess that would be quite good. It's very
standard and sensible to have your reflection map seperate from the
material. Reflection maps are applied/shared by meshs in the context of
the environment (though sometimes blurred etc) and a material is
merely... a material

What I mean by reflection map is a dynamic texture the engine generates at runtime that stores the reflection about some plane (usually a water plane). The reason it is related to the "material" is because my material needs to know what resources to bind to the shader stages. And for a water material, the reflection map will need to be specified.

You could have a separate "planar reflection" object, which as a list of
renderables which use it. It can check if any of these objects are
visible to the current camera, and if so, it needs to generate it's
texture. When those renderables are rendered, they can source the
appropriate state (i.e. texture binding) from this object.

Something like this would work.