Are you talking about deferred shadows?

Yes, with deferred shadows you collect lighting information into a full screen buffer (sometimes called a shadow collector), which is later used by the lighting shaders.
This is also nice because it breaks the dependency between lighting and shadowing into two different shaders. On my last game (which was forward rendered - but this idea works equally well with deferred shading), for different scenes, we supported either using screen space shadows (SSAO-inspired), stencil shadows, projected shadows, static lightmaps, and/or regular shadow maps to fill in the "shadow collector" texture, which was later used by the forward-lighting shaders (without them having to care where shadows came from). We could even mix multiple of the above shadowing techniques for different lights/objects, and the regular forward-lighting shaders stayed the same!

On another game I've worked on, instead of one shadow map per light, we used one shadow map per light per object. So if there were 10 cars on a track with 2 lights, we'd do 20 shadow-map passes, where each pass only rendered a single car. Each pass could share the same shadow map resource (making great use of it's resolution) after the previous pass had been applied to the full-screen collector.

http://developer.amd..._CryEngine2.pdf
http://aras-p.info/b...ed-shadow-maps/
http://mynameismjp.w...ow-maps-sample/

Besides "deferred shadows", regular deferred shading can be implemented in the same "recycling" manner without making use of a full-screen shadow collector. Instead you simply render the shadow map(s) for a light, and then perform the deferred light accumulation for that light, then goto next light, etc...

Also, why would you go through the trouble of using an enlarged viewport instead of a texture array? Are texture arrays undesirable for any reason?

As Lauris mentioned above, you can dynamically resize your viewports to have different resolution shadow maps. e.g. a 2048^{^2} texture could hold 4*1024^{^2} maps, or 1*1536^{^2} plus 7*512^{^2} maps.
Also, older hardware doesn't support texture arrays, so depending on your minimum specifications, they might not be an option.

Are you talking about deferred shadows?

Yes, with deferred shadows you collect lighting information into a full screen buffer (sometimes called a shadow collector), which is later used by the lighting shaders.
This is also nice because it breaks the dependency between lighting and shadowing into two different shaders. On my last game (which was forward rendered - but this idea works equally well with deferred shading), for different scenes, we supported either using screen space shadows (SSAO-inspired), stencil shadows, projected shadows, and/or regular shadow maps to fill in the "shadow collector" texture, which was later used by the forward-lighting shaders (without them having to care where shadows came from). We could even mix multiple of the above shadowing techniques for different lights/objects, and the regular forward-lighting shaders stayed the same!

On another game I've worked on, instead of one shadow map per light, we used one shadow map per light per object. So if there were 10 cars on a track with 2 lights, we'd do 20 shadow-map passes, where each pass only rendered a single car. Each pass could share the same shadow map resource (making great use of it's resolution) after the previous pass had been applied to the full-screen collector.

http://developer.amd..._CryEngine2.pdf
http://aras-p.info/b...ed-shadow-maps/
http://mynameismjp.w...ow-maps-sample/

Besides "deferred shadows", regular deferred shading can be implemented in the same "recycling" manner without making use of a full-screen shadow collector. Instead you simply render the shadow map(s) for a light, and then perform the deferred light accumulation for that light, then goto next light, etc...

Also, why would you go through the trouble of using an enlarged viewport instead of a texture array? Are texture arrays undesirable for any reason?

As Lauris mentioned above, you can dynamically resize your viewports to have different resolution shadow maps. e.g. a 2048^{^2} texture could hold 4*1024^{^2} maps, or 1*1536^{^2} plus 7*512^{^2} maps.
Also, older hardware doesn't support texture arrays, so depending on your minimum specifications, they might not be an option.

Are you talking about deferred shadows?

Yes, with deferred shadows you collect lighting information into a full screen buffer (sometimes called a shadow collector), which is later used by the lighting shaders.
This is also nice because it breaks the dependency between lighting and shadowing into two different shaders. On my last game (which was forward rendered - but this idea works equally well with deferred shading), for different scenes, we supported either using screen space shadows (SSAO-inspired), stencil shadows, projected shadows, and/or regular shadow maps to fill in the "shadow collector" texture, which was later used by the forward-lighting shaders (without them having to care where shadows came from). We could even mix multiple of the above shadowing techniques for different lights/objects, and the regular forward-lighting shaders stayed the same!

On another game I've worked on, instead of one shadow map per light, we used one shadow map per light per object. So if there were 10 cars on a track with 2 lights, we'd do 20 shadow-map passes, where each pass only rendered a single car. Each pass could share the same shadow map resource (making great use of it's resolution) after the previous pass had been applied to the full-screen collector.

http://developer.amd.com/Resources/documentation/presentations/legacy/Chapter8-Mittring-Finding_NextGen_CryEngine2.pdf
http://aras-p.info/blog/2009/11/04/deferred-cascaded-shadow-maps/
http://mynameismjp.wordpress.com/samples-tutorials-tools/deferred-shadow-maps-sample/

Also, why would you go through the trouble of using an enlarged viewport instead of a texture array? Are texture arrays undesirable for any reason?

As Lauris mentioned above, you can dynamically resize your viewports to have different resolution shadow maps. e.g. a 2048^{^2} texture could hold 4*1024^{^2} maps, or 1*1536^{^2} plus 7*512^{^2} maps.
Also, older hardware doesn't support texture arrays, so depending on your minimum specifications, they might not be an option.