Nice question - made me read some new documentation.
Interesting new feature, but rather a boring one. It's a pity they've only done the really pedestrian option - work on whole tables regardless of size - so that the whole thing is effectively equivalent to using 4-part names to split a database in two. Plenty people will have done that before, and while this may save a bit of design and coding effort it offersabsolutely no new capability.
It's it's not just a boring marketing excercise, which is what option 4 of the answers would have been. The first two answer options - or actually something a good deal better than either - have been available for at least 15 years on any reasonable interpretation of the wording. So that left only option 3, and when I read about it to confirm that it really did fit that option I was quite disappointed by the total absence of any new capability for us users.
I wonder why MS haven't done this as an excercise that splits an individual table into historical and current, with a parameter for each indicating which is the oldest date which should be kept as current and another which indicates which is teh
newest date that may be treated as historical (each of course as an offset before current date); maybe that would