その通りですね。ハイライト用に異なるstoredフィールドを使用することが要望されています。関連するJIRAの問題とパッチがあります。
https://issues.apache.org/jira/browse/SOLR-1105
自分自身でこれを進めるのは忙しすぎますが、もしそちらで引き継いでいただけるなら、私（または他の誰か）が協力します。

〜 David Smiley
Apache Lucene/Solr 検索開発者
http://www.linkedin.com/in/davidwsmiley

これは有用ですね。ありがとうございます、David。
ただし、私の場合、おっしゃる問題への解決策がこの問題を解決するとは思いません。

その理由は次のとおりです。
私はハイライト用に他のフィールドを指定したくないのですが、同じコピーフィールドの宛先フィールドを使用したいと考えています。
なぜなら、私の場合、これらのコピーフィールドの宛先フィールドが「完全一致」フィールドだからです。したがって、ハイライトがこれらの完全一致フィールド（ステム処理されていない、同義語なしのフィールド）で機能することが重要です。

また、ハイライト時に他のフィールドを指定する必要がある場合、hl.flパラメータでそれを上書きできないのでしょうか？つまり、qfパラメータで検索用のフィールドf1を使用し、hl.flパラメータでフィールドf2を使用するだけです。contentFieldパラメータが必要なのはなぜですか？

100％はっきりしませんが、もっと明確にf1またはf2のどちらが格納されているか、copyFieldがどのように行われるか、すでに「qf」にリストされているフィールドを示していただける仮想的な例を使用できるかもしれません。

そのJIRAの問題を最後に見たのはしばらく前なので、具体的な機能を想像しています。たとえば、UH（ハイライティングコンポーネント）が特定のhl.flフィールドが「格納されていない」ことを認識し、このフィールドが一つのcopyField宣言の宛先であり、そのソースが「格納されている」ことを自動的に検出したり、その逆の場合―別の格納されているフィールドにコピーされる場合―を考えています。

〜 David Smiley
Apache Lucene/Solr 検索開発者
http://www.linkedin.com/in/davidwsmiley

似たような機能を調査しており、SOLR-1105が修正になる可能性があると考えています。その理由は、ハイライトがクエリ実行時に行われるため、格納されたフィールド値がまずインデックスの解析器を通過し、次に検索がクエリの解析器を通過するからです。