デフォルトでは、apple.laf.AquaLookAndFeel になるようです。
VF1.1.3では、コンボボックスのポップアップメニューにて ↓Keyなどを押下するとExceptionが発生します。 これは、VF1.1.3ではMetal用に整備されているためです。
MacにてMetalに変更して動作する事は可能ですが、 Metal では コンボボックスに不具合が あるのが分かりました。(VF関係なく、JDKの不具合)
コンボボックスのポップアップを表示後、他コンボボックスのポップアップメニューを表示すると、前回表示 された内容が表示されます。(リペイントされていない？ ↓Keyなどで選択移動すると表示は正常に戻る)

そこで、1.1.4では AquaLookAndFeel でも動作するようにコンボボックスの修正を行っています。
AquaLookAndFeel にて動作した場合、以下の動きの差が発生します。
項目チェックエラーになる状態にて、コンボのボタン部(▼の部分)をクリックすると、一瞬ポップアップメニューが 表示され、閉じます。
フォーカスは項目チェックエラー部に移動するため、画面内不整合は発生しないようになっています。

但し、AquaLookAndFeelなど MatalLookAndFeel以外を使用された場合、コンボに対する、選択背景色・前景色などは 行えなく(設定されても反映されない)なります。

テキストフィールドなどにフォーカスを当てた状態で画面を非表示にし、画面再表示をすると、フォーカスが見た目上 なくなります。(実際には 画面自体にフォーカスが当たります)
これは、Macのウィンドウマネージャーの動作になります。(javaの世界では制御できません)
この部分はVFにて回避できないため、そのままの挙動になっています。

上記現象は、
画面情報保持 を HIDE_ON_CLOSE に設定しフレームの種類を ***_QUIT_ON_CLOSE にした場合に発生する可能性が でてきます。
そのため、HIDE_ON_CLOSE は使用しない 事をお勧めします。

AquaLookAndFeel では、コンボボックス確定Keymapの設定が異なります。
ここでいう確定処理というのは、コンボのポップアップメニューを表示した状態にて、選択・確定する動作になります。

編集不可コンボ

	Enterキー	Spaceキー	マウスクリック	パネルをマウスクリック
MetalLookAndFeel	○	○	○	○
AquaLookAndFeel	○	×	○	×

編集可コンボ

	↓キー	↑キー
MetalLookAndFeel	○	○
AquaLookAndFeel	×	×

これらの差は、LookAndFeelによる差になりますので、VFでは統一するような制御は行いません。

AquaLookAndFeel では、テキストフィールドなどの文字を複数選択されている状態では、キャレットは表示されません。
(MetalLookAndFeelでは表示されます。)
そのため、項目チェックエラーなどで全選択を行うような動作をした場合、キャレットは表示されなくなります。
この差は、LookAndFeelによる差になりますので、VFでは統一するような制御は行いません。

テキストフィールド等にフォーカスがある状態にてボタンのニーモニックKeyを押下すると、押下されたKeyの情報が テキストフィールドに入力されます。(+ボタンも押下されます)
Windows上javaでは、ニーモニックKey情報はテキストには反映されません。
この差は、MacOSの挙動 もしくは Mac用JDKの挙動 になるため、VFでは制御を行えません。
(Javaハードコーディングによるテストでも同様の挙動が発生します。)

Macにて使用する場合には、ニーモニックKeyの設定は行わないようにする方が無難かと思われます。

MacにてFunctionKey(F1〜F10)を押下すると、OSにてKeyイベントが消化される場合があるため、javaのアプリには そのKeyEventが渡ってこない事があります。
結果、アプリにてFunctionKeyMapを登録しても動作しなくなります。

Macにて使用する場合には、FunctionKeyのKeymapは登録しないようにして下さい。

一連の処理にて、Modalダイアログ表示が2回以上発生する場合 2回目以降のダイアログについて画面自体にフォーカスが 当たった状態にて表示されます。
例えば、OKボタンのみのModalダイアログを2回実行した場合、
1回目のダイアログ表示時は OKボタン にフォーカスが当たった状態にて表示されますが、
2回目のダイアログ表示時は OKボタン にフォーカスが無い状態になります。
(ダイアログ自体にフォーカスが当たった状態。つまり、Tabを1回押下すると OKボタンにフォーカスが移動する)

また、ダイアログ表示が1回のアプリでもフォーカス移動処理が伴う場合には同様の現象が発生する可能性があります。
テーブルエディタなどでのModalDialog表示などでも同様の現象が発生する可能性があります。
画面起動後、1回目の動作と2回目の動作にて、フォーカス有無の挙動が変わる場合もあります。

この挙動は、Mac+Java での動きになり、VFエンジンでは制御できないため、VFアプリでも同様の現象が発生します。

(Mac+Java にて確認した所、動作統一性がない、同ソース同操作を行っても同じ結果にならない など不安定な部分が 多く、VFエンジンにて制御が出来ない為です。
但し、VFでは内部的に整合性を合わせる制御をしているため、データ不整合などが発生するパターンは確認されていません。)

テキスト系コンポーネントを使用不可の属性に設定した場合でも、カーソルは I (Iビーム) になります。
(Windowsでは 通常のカーソル(矢印) になります。)
この挙動は、Mac + AquaLookAndFeel、Mac + MetalLookAndFeel ともに発生します。
(そのため、OSによる差と思われる)

この挙動は、VFエンジンにて統一する制御は行わないため、VFアプリでも同様の現象が発生します。

Windowsでは グリニッジ標準時 00:00:00.000 からの経過時間 が入るのに対し、 MAC では PC起動からの経過時間がはいります。
また、MAC上にて Java上にて発火されるイベント(InvocationEventなど)はグリニッジ標準時 00:00:00.000 からの経過時間 になるため、InputEventとに時間取得仕様の差が生まれます。
これらの差を回避するため、VFエンジン Ver1.1.4 では制御が入っていますが、独自ユーザルールにて処理される部分について 影響がないかどうか？考慮する必要があります。

LookAndFeelにより画面作成を行う部分では、MetalLookAndFeelと比べて表示差が発生します。
VFエンジンにて表示しているチェックエラーダイアログや、標準ルールの メッセージダイアログ などは、JOptionPaneを 使用していますが、JOpotionPaneでの画面構成はLookAndFeelに依存しています。
そのため、画面内の Yes,Noボタンの配置場所が異なったり、ボタンのショートカット機能反映有無などが異なったり します。
テーブル(レンダラ)にて、MetalL&FではCell枠線がありますが、MacではCell枠線は表示されません。

ボタンコンポーネントの背景色を設定すると、MetalL&Fではボタン自身の背景色が設定されますが、 AquaL&Fでは ボタン自身の背景色は設定されず、ボタン外の色が変更されます。

AquaL&Fでは チェックボックス、ラジオボタンのBorderの設定は反映されません(AquaBorderになります)

その他も細かな表示差があると思われますが、現在調査中です。