Linux上のFreePascalでcsakuraをコンパイルして作られたコンソール版バイナリで、エラーになる行を含むMMLをコンパイルすると、MMLテキストの何行でエラーが出ても常に行番号は0と表示されます。
これはたぶん行末コードの問題で、TStringList.LoadFromFileでテキストファイルを読み込んだ後、TStringList.Textで行末コード区切りの文字列を取り出す時、UNIX系OSだとTStringList.LineBreakのデフォルト値が#10(LF)なので、取り出された文字列が#10区切りになっていることが原因だと思われます(MMLの解析処理内部では#13#10を見て行カウンタをインクリメントしているようなので、#10区切りの文字列だとMMLをコンパイルすることはできても行カウンタが0から増えない)。Textで文字列を取り出す前にLineBreakを#13#10(CR+LF)に設定すると良さそうです(具体的には、csakura.dprの「src := s.Text;」の前に「{$IFDEF UNIX} s.LineBreak := #13#10; {$ENDIF}」とか入れる。ヘッダファイルを読み込んでいるところでも同じような処理が必要)。
これをやってもエラー行は1行ずれているのですが、エラーメッセージを出力するときに+1してやればいいのではないかと(変数の時点で+1すると、DLLとしてコンパイルして外部に渡す値にも影響が出るかもしれないので)。そういえばRust版も今のところエラー行は0行スタートになっているみたいですね。
ついでにもういくつか。
現状ではエラーメッセージは同じ内容のものが2回表示されているので、csakura.dprの「Failed..」の後のやつはいらないのではないかと。
インクルードファイルを探す処理で、環境変数Path以下を探すところ、環境変数の区切り文字をセミコロン固定にしているので現状ではWindowsでしか動かないと思われます。あと、環境変数名がPathとして処理していると、UNIX系OSの環境変数PATHを参照しないのではないでしょうか(たぶん、環境変数名でも大文字小文字は区別されている)。
それと、コメント文だけでもUTF-8の日本語を書いても問題ないようにしていただけると嬉しいです。現状ではSkipComment系の処理においてはLeadBytesに該当するバイトコードを見つけると2バイト分進める処理をしているので、1行コメントの終わり(つまり、改行コードの直前)に例えば「め」(E38281)のように終端バイトがLeadBytesの範囲内で終わる文字を書いてしまうと改行コードを食ってしまって誤作動の原因になっていますね。
ダウンロードページの「コンソール版サクラ」がダウンロードできないようですね。
長々と失礼しました。