pdfpages 最新版が release されました。dvi モードでは
将来のためドライバ dvips もサポートしたいということで，
dvipdfmx の場合は，
%
% (u)platex + dvipdfmx
%
\documentclass[dvipdfmx]{jsarticle}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages={3,5,7},lastpage=9]{foo.pdf}
\end{document}
のように class option を dvipdfmx にしてくれということです。
%
% (u)platex + dvipdfmx
%
\documentclass{jsarticle}
\usepackage[dvipdfmx]{pdfpages}
\begin{document}
\includepdf[pages={3,5,7},lastpage=9]{foo.pdf}
\end{document}
でも動作しますが，graphics package に関して warning が出ます。
%
% (u)platex
%
\documentclass{jsarticle}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages={3,5,7},lastpage=9]{foo.pdf}
\end{document}
とした場合は，将来のための dvips モードとなります。
lastpage は不要の場合もありますが，指定するようにした
ほうが良いでしょう。(これが pdfTeX の場合とちがって少し不便な点)。
あべのりさんのパッチを含むものとなり，(u)platex + dvipdfmx の場合も
lastpage の指定は不要になりました。
使用上の注意:
o ページごとに BoundingBox が異なる PDF を採りこむ場合には，
.xbb ファイルを作らないこと。
この場合は，パフォーマンスがかなり落ちます。
理由は，外部プログラム extractbb を多数回呼ぶため。
o 各ページが同じ BoundingBox を持つことがわかっている場合には
.xbb ファイルを予め作成しておくと，パフォーマンスが劇的に
上がります。pdfTeX や XeTeX の場合と同程度と思ってよいでしょう。
理由は, 外部プログラム extractbb を呼ばないで済むからです。
pdfTeX や XeTeX の場合にパフォーマンスが良いのは，TeX エンジン
自身が各ページのサイズを取得できるからです。
lastpage の指定は不要になりました。
使用上の注意:
o ページごとに BoundingBox が異なる PDF を採りこむ場合には，
.xbb ファイルを作らないこと。
この場合は，パフォーマンスがかなり落ちます。
理由は，外部プログラム extractbb を多数回呼ぶため。
o 各ページが同じ BoundingBox を持つことがわかっている場合には
.xbb ファイルを予め作成しておくと，パフォーマンスが劇的に
上がります。pdfTeX や XeTeX の場合と同程度と思ってよいでしょう。
理由は, 外部プログラム extractbb を呼ばないで済むからです。
pdfTeX や XeTeX の場合にパフォーマンスが良いのは，TeX エンジン
自身が各ページのサイズを取得できるからです。
> この場合は，パフォーマンスがかなり落ちます。
> 理由は，外部プログラム extractbb を多数回呼ぶため。
BoundingBoxをキャッシュさせてみる，という実験をしてみました．ただ，通常の\includegraphicsの場合は一度しか呼び出されないのが普通だと思うので，あまり意味が無いかもしれません……．一応手元で5ページのpdfを\includepdfしてみた限りでは，6.7秒→2.6秒となりました．
> 理由は，外部プログラム extractbb を多数回呼ぶため。
BoundingBoxをキャッシュさせてみる，という実験をしてみました．ただ，通常の\includegraphicsの場合は一度しか呼び出されないのが普通だと思うので，あまり意味が無いかもしれません……．一応手元で5ページのpdfを\includepdfしてみた限りでは，6.7秒→2.6秒となりました．
pdf@bbox@cache\Gin@page @sep@#1
を
pdf@bbox@cache\Gin@page\GPT@pagebox @sep@#1
で両立するみたいですが，よいでしょうか?
\expandafter\expandafter\expandafter\xdef\expandafter\csname\@tempa\endcsname{\@gtempa}
は
\expandafter\expandafter\expandafter\xdef\expandafter\csname\@tempa\endcsname{\@gtempa}%
のように % を付けないと，スペースが入ることがあるようです。
を
pdf@bbox@cache\Gin@page\GPT@pagebox @sep@#1
で両立するみたいですが，よいでしょうか?
\expandafter\expandafter\expandafter\xdef\expandafter\csname\@tempa\endcsname{\@gtempa}
は
\expandafter\expandafter\expandafter\xdef\expandafter\csname\@tempa\endcsname{\@gtempa}%
のように % を付けないと，スペースが入ることがあるようです。
一応patchの形式にしてみました．（ちょっとキャッシュ用マクロ名を変更してあります．）W32TeXのものに対してです．TeX Liveのものにそのまま当てると\GPT@pageboxが定義されていないのでエラーになるようです．
新しい dvipdfmx.def ですが，\@tempx がグローバルに
\let\@tempx\ltx@empty
と定義されており，\includegraphics 実行時にこの定義が保持されていることが仮定されています。
そのため，他のパッケージなどが \@tempx を再定義してしまうと，extractbb 実行時におかしな引数が渡ってしまうことに気づきました。
【例】
\documentclass{article}
\usepackage[dvipdfmx]{graphicx}
\makeatletter
\def\@tempx{"}
\makeatother
\begin{document}
\includegraphics{hoge.pdf}
\end{document}
この例の場合，
\immediate\openin\@inputcheck="|extractbb \@tempx \@tempc -O \Gin@base\Gin@ext"
の部分が
"|extractbb " -O hoge.pdf"
となってしまい，おかしなことになります。
\@tempx を，\GPT@pagebox@option のように，他とぶつかりにくい名称に変更しておくとよいと思います。
\let\@tempx\ltx@empty
と定義されており，\includegraphics 実行時にこの定義が保持されていることが仮定されています。
そのため，他のパッケージなどが \@tempx を再定義してしまうと，extractbb 実行時におかしな引数が渡ってしまうことに気づきました。
【例】
\documentclass{article}
\usepackage[dvipdfmx]{graphicx}
\makeatletter
\def\@tempx{"}
\makeatother
\begin{document}
\includegraphics{hoge.pdf}
\end{document}
この例の場合，
\immediate\openin\@inputcheck="|extractbb \@tempx \@tempc -O \Gin@base\Gin@ext"
の部分が
"|extractbb " -O hoge.pdf"
となってしまい，おかしなことになります。
\@tempx を，\GPT@pagebox@option のように，他とぶつかりにくい名称に変更しておくとよいと思います。