Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ...
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure

Yeah I agree, a overly generous range seems like it should be safe, and practice tells us that it is safe (so far )

For curiosity, the only hypothetical situation I can think of is:
Let's assume we're only using [font=courier new,courier,monospace]D3DPT_TRIANGLELIST[/font] and [font=courier new,courier,monospace]DrawIndexedPrimitive[/font].
The driver is emulating vertex processing, but it's done by a worker thread. The [font=courier new,courier,monospace]PrimitiveCount[/font] param is summed over a whole frame, and the sum multiplied by 3 to calculate the maximum number of verts required. To allow maximum latency, a whole-frame vertex buffer is constructed of the previously calculated max size. At the end of a frame (after this buffer's been created) the worker thread is alowed to start.
For each [font=courier new,courier,monospace]DrawIndexedPrimitive[/font] call, the worker thread reserves a portion of the whole-frame vertex-buffer equal to the draw-call's [font=courier new,courier,monospace]NumVertices[/font] value (the number of unique verts to be processed). With a generous [font=courier new,courier,monospace]NumVertices[/font] value, the whole-frame vertex-buffer will be depleted before all draw-calls have been processed, which will result in either: GPU-readable vertex allocation to extend a ring-buffer, complex CPU/GPU ring-buffer stalling routines, or when those fail or aren't implemented: simply aborting the draw-call in (silent) error...