When setting up maps in Weave you need to understand that your are configuring 2 completely different things when you're setting up map engines.

Server Map Engine

Firstly there are server side map engines, these are the things that talk directly to ArcGIS Server, ArcIMS or a WMS server and this is what he Weave server uses to generate map images (both for the browser and for reports, plus anything else that requires a map image, but those things aren't important for this discussion).

These are top level configuration items, and therefore require the namespace in their configuration(e.g. <arcims:mapengine id="...">, <arcgis:mapengine id="..."> or <wms:mapengine id="...">), because it's the namespace that directs the chunk of configuration xml to the correct bundle to process it, and each of these types of map engines is handled by a different bundle.
This way we can add new types of objects just by adding a new bundle and giving it a new namespace (this applies to any top level configuration item, and not just map engines).
These setup the basic settings that Weave requires in order to know how to talk to the respective map service (e.g. userid, url, service names, connection pooling), think of something like a database connection, where different databases require different setting depending on the manufacturer (Oracle, Microsoft), but in the end to Weave it's still just a database.

Client Map Engine

The second part are the client side map engines which describe to the browser what map layers you want to display in the map panel.
These are not top level configuration items, and they only make sense within the context of a map view inside of a client config, so they don't require a namespace (actually they already have a namespace because they're always inside of a client config). Basically they're used to configure an OpenLayers map component.
At their simplest a client side map engine only needs to be provided with the id of a server side map engine <mapengine id="server_mapengine_id"/>, in which case the rest of the stuff that's needed for OpenLayers is figured out by Weave based on what was configured in the server side map engine that has the same id.
Additionally you can provide a few options in the client map engine config to alter slightly the layer that OpenLayers creates (things like the transition effect and opacity), these optional settings are applied to the OpenLayers component effect the way the map image is displayed/generated from the client perspective.

Map Image Generation

If you do nothing more that this then each time the browser wants to update the map display it'll send a request to the Weave server asking to update the image related to a particular map engine (as part of the request the map engine id is sent, along with the map extent, screen size, visible layers, etc), it doesn't care what type of map engine it is on the other end (ArcIMS, AGS or WMS) it just wants a picture back.
When the request gets to the server it looks up the corresponding server side map engine and uses the information in the request to generate a new bitmap image using the appropriate API (generating AXL for ArcIMS, constructing a URL for WMS or using the AGS SOAP API for ArcGis server).
The image is generated and returned to the browser which then updates the display.

All of the above happens because the default type for a layer added to the OpenLayers component in the Weave client is set to "weave". That is, if you don't set the type in a client side map engine explicitly Weave sets it to "weave", which is an OpenLayers layer implementation that we created for OpenLayers which knows how to talk to a Weave server to generate map images.

Map Layer Types

From that you can gather that OpenLayers supports other layer types, for example "wms" where the browser can talk directly to a WMS server to generate map images, not needing to communicate to the Weave server at all.
There are actually a handful of these other OpenLayers layer types including one for talking to ArcIMS, one for ArcGIS and a handful for directly accessing map tiles among others.
Each one has their own configuration options requires parameters, as defined by OpenLayers.

But there's one small issue with these other OpenLayers layer types, the Weave server doesn't know anything about them. This isn't really a problem until you try and generate a report with a map in it (or do anything else that requires that the server generate a map image that represents what the user us seeing on their screen).
Since the Weave server doesn't know anything about the layers the OpenLayers was accessing directly it can't draw the layers on the map that it's trying to create and the resultant map image won't match what the client was viewing.

Linking Client Layer to Server Map Engine

Fortunately there's a way around this, allowing you to gain the performance of having the client directly access the map engine whilst still allowing the server to generate a map image that matches the client.
And that's by configuring the client map engine with information about a server side map engine that can be used to replicate the map image on the server.
For example in the case of the client side "wms" layer type you would setup a corresponding server side map engine pointing to the same WMS server using the same base URL that the client was configured with.
Then you'd add a <server> section to the client map engine configuration telling it which server side map engine the server should use if it's ever asked to draw a map that includes that particular OpenLayer layer.

ArcGIS Server

All of that can get a little messy, or a lot messy when trying to do this with tile caches, so to make life easier for sites wanting to use ArcGIS Server tile caches, which are inherently a client side mapping option, Weave does a bunch of extra stuff to take care of a lot of the manual configuration that would normally be required (believe me you do not want to have to manually setup a client side ArcGIS tile cache).

Basically if Weave sees that you're referencing a server side ArcGIS map engine in your client config, and that map service supports tile caching, then it'll query the ArcGIS server to obtain the information that describes the tiles and use that to alter the client side map engines config, it will also change its type from "weave" to "agstiled" (for a single fused map cache) or "agsrest" (for a multi-layer map cache), and finally add the required server tags so the server knows what server side map engine to talk to if required.
So generally to make use of an ArcGIS tile cache nothing explicitly has to be done, either in the server side map engine or the client side configuration (in fact you have to explicitly include a setting to disable use of the cache if it's available).

Directly accessing ArcGIS tiles

Both of the ArcGIS layer types referenced above, "agstiled" and "agsrest", still talk to an ArcGIS Server instance, they just do it from the browser rather than the Weave server. So, while they're quicker than going via the Weave server they're still not the quickest option, which is going to the tiles directly (well, via a web server, but that happens with the other too as well). Of course accessing the tiles directly has the down side that the tiles must already exist, where as these 2 option can dynamically generate the tiles when they're asked for.

Accessing the tiles directly it turns out is almost exactly the same as accessing them via the "agstiled" method. The only difference is the base URL that the tiles are accessed from, for the "agstiled" method the base URL points to the ArcGIS server, e.g. http://hostname:8399/arcgis/services/imagery/ but for directly accessing the tiles it's something like http://hostname:80/tiles/imagery/, and the rest of the URL, the part that actually describes the tile to retrieve, is exactly the same (it includes the level, row, column and format).
One other difference is in the way the level, row and column are formatted when talking to ArcGIS verses accessing the tiles directly, which is why the <useArcGISServer> option must be set to false in the client map engine configuration if you want to alter the map engine to access the tiles directly.

So to directly access pre-generated ArcGIS tiles you just need to setup things so that an "agstiled" client side map engine is used and change its URL parameter. The first part can be done by ensuring that the client map engine points to a server side map engine that is setup to serve a fused map cache (so that Weave will perform the automatic processing required to set all the other parameters that are needed) and the second part can be accomplished by setting the <url> parameter for the client side map engine (thereby overriding the one the URL Weave would generate to access the tiles via the ArcGIS server).

Other Layer Types

At the moment ArcGIS tile caches are the only client side map engine that Weave performs the extra processing on, but it may be possible to add similar functionality for ArcIMS and WMS (not that it's add support for tile caches to these 2 map engine types) or to the other tile caching formats that Weave/OpenLayers support (e.g. TileCache, TMS and OpenStreetMap) but that's a problem for another day and at the moment you have to manually figure out what values are required for the various layer types.

Browser not supported