dvipdfmx 使用時
png や jpg 画像などを \includegraphics で取り込むときのトリミングなのですが、
.xbb ファイルが存在していても、bb を指定しておかないと trim が効かなくなっています。
これは dvipdfmx.def の \Ginclude@bmp の定義において、下記に矢印で示した if が
あるためです。この if は必要でしょうか??
\def\Ginclude@bmp#1{%
\message{<#1>}%
\bgroup
\def\@tempa{!}%
\special{pdf:image\space
\ifx\Gin@page\@tempa\else page\space\Gin@page\space\fi
\ifGin@bbox %% ←これ
bbox\space\Gin@llx\space\Gin@lly\space\Gin@urx\space\Gin@ury\space
clip\space\ifGin@clip 1\else 0\fi\space
\fi %% ←これ
\ifx\Gin@scalex\@tempa\else width\space\the\Gin@req@width\space\fi
\ifx\Gin@scaley\@tempa\else height\space\the\Gin@req@height\space\fi
(#1)\space
\ifx\Gin@mask\@tempa
\ifGin@interpolate<</Interpolate\space true>>\fi
\else
<</SMask @\Gin@mask\space%
\ifGin@interpolate/Interpolate\space true\fi>>%
\fi}%
\egroup}
既に graphics/x 本体のマクロに手を付けてしまっている状態だとすると、私だったら、
\g@addto@macro\Gin@viewport{\Gin@bboxtrue}\g@addto@macro\Gin@trim{\Gin@bboxtrue}
(で special の bbox 出力は変更無)
も検討するかも知れません。
でも、「\Gin@olly を検査する」の方が（本体のマクロの修正がないので）よさそうです。ただ、\@ifundefined を使うと「\relax-化」が起こるのが何となく嫌（もちろん無害なのですが）なので、直接 \ifx で判定したいところです。
\ifx\Gin@ollx\@undefined\else bbox... \fi
(2) について。
実は、hiresbb が指定された場合、“readファイル”に %%HiresBoundingBox がないとエラーになります。つまり、%%BoundingBox があってもそちらにフォールバックしてくれません。
ビットマップ画像の場合、読取対象は extractbb が吐いた .xbb ファイルに決まっているので %%HiRes～ が必ずあるはずですが、EPS 画像ファイルの場合、%%Hires～ は無いことが結構あります。
しかし、「ビットマップの場合だけ hiresbb を既定にする」ことは妥当がと思います。graphics パッケージの仕様との整合性も考慮する必要がありますが、hiresbb は「eps タイプの画像の場合のみを規定する」とも解釈できるでしょう。（例えば pdfTeX の場合は hiresbb オプションは無関係です。）