define-packet-formatをSRFIにするには

地味にFFIをSRFIにするより難しいんじゃないだろうか。

命名

まず命名が良くない。Schemeコミュニティは省略されない説明的な名前を好むが、yuniは可能な限り多くの人にプロトコル定義を書いてもらわないと価値を発揮しないので名前は可能な限り短く簡潔にしたい。
一貫性のためには、define-packet-descriptor-typeのような名前にすべきだろう。しかし、一般的なセンスから行くとこの名称はちょっと長すぎる。
ERR5RSのrecordのように、省略名を使っている例外も有る(R6RSのmake-record-type-descrptorをERR5RSではmake-rtdとしている)ので、よりよい略語を考えるべきかもしれない。

シンボルの扱い

最もSchemerからの評価が悪そうなのは階層化シンボルで、仮に標準化するならこの仕様は真っ先に代替策を用意すべきだろう。
yuniは、シンボルを階層化し親子関係を持たせている。また、長すぎるパスを短くするためにエイリアスを持ち、エイリアスはeq?の意味で元のシンボルと等しい。
エイリアスは、もうどうしようもないので廃止するのが好ましいだろう。
階層化シンボルは / で区切って記述する。

<atomic scheme symbol> ::= <initial> { <letter> | <digit> }*
<structured symbol> ::= <atomic scheme symbol> { "/" <yuniobj> }+
<yuniobj> ::= <atomic scheme symbol> | <decimal integer number> | "0" "x" <hex digit>* | <dict keyword>

例えば、 hoge/0 は (hoge 0)を表現する階層化シンボルとなる。
もっとも、SRFI-88よりも状況が良いのは、keywordと異なり、この階層化シンボルは単体でSchemeシンボルとして有効で、原理的にはsyntax-caseで取り扱うことが出来る。
階層化シンボルは記述を簡潔に行うために導入されている。(プロトコル記述言語にとって最も重要なのは普及することなので、この要求事項は優先度が高い)

A:
(define-packet-format hoge ...)
(define-packet-format hoge/fuga ...)

B:
(define-packet-format hoge ...)
(define-packet-format (hoge fuga) ...)

yuniでは、構造体hogeのフィールドfugaをさらに構造体にすることが出来る。それを表現するためにhoge/fugaのような階層化シンボルを使う。Bのような表記を行う場合、これは単体でシンボルとして妥当で無いため、何らかのprefixを追加しなければマクロを使わずに各種手続きを実装することが出来ない。
他に階層化シンボルの使い道を思いつけばそれ単体で標準化をする方向性も有るかも知れない。。

他のScheme規格と一貫性がない

define-packet-formatは元々Schemeベースでない独立した言語だったので様々な習慣が(AOTコンパイラが効率的なコードスケジューリングができるように)異なっている。
一つは、record-type-descriptorを拡張して、"シリアライズ可能な"rtdを概念として導入することだろう。
しかし、これでも、バイト列とSchemeのdatumの対応をちゃんと定義する必要があり、そのモジュールはかなり大規模になってしまう。要するに、現状のレコードの階層構造を維持したまま、現状のdefine-packet-formatによるプロトコル記述言語をSchemeに統合するためには :

ライブラリ(srfi :xx)。手続きレイヤ。make-serializable-record-type-descriptorやasciiのような必要な名前を定義する。
ライブラリ(srfi :yy)。文法レイヤ。define-packet-formatや+ -のような、必要なプリミティブをエクスポートする。辞書を定義するための補助構文define-dict。

難しいのは、手続きレイヤはyuniのフルセット(これはletとかdefineも含んでいる)をエクスポートする可能性が有ることで、"プロトコル記述を行うSchemeライブラリのためのライブラリ"と、"プログラム中にパケット記述を含めるためのライブラリ"は明らかに分離されなければならない。
また、yuniの記述はimplicitなエクスポートを多く含む。階層化シンボルをエクスポートするために必要なのはrootをエクスポートすることだけなので、意図せずシンボルが衝突する可能性は有る。もちろん通常のR6RSライブラリ実装は、全ての可能な階層化シンボルをエクスポートする必要がある。