I think basically all of enum PlayBehaviour could be exposed as ctls. ctls are settable even after loading by using ctl_set(). Unless implemented load-time specific explicitly, ctls will also and are supposed to work during play time by default.
I dont think it would make much sense to define render_params for those (and thereby make them completely realtime-safe that way), at least at first (especially as the expected use of these ctls should be rather rare as libopenmpt is supposed to do the best guess right thing by default).

I don't think it is really necessary to expose all of PlayBehaviour - most of it can be accurately determined at load-time and should never be changed by the user. The amount of (sometimes rather insufficiently documented) behaviour flags there would probably just confuse any library user (both developer and end-user). The number of play behaviours that are actually relevant to be settable via ctls is really low.

An interesting approach could be to have different "player types" which could be queried. For example, for S3M files, player types could be "ST3 with GUS", "ST3 with SoundBlaster", "Impulse Tracker", and these player types would be associated with certain sets of playback flags. For MOD, different ProTracker versions and other tools could define certain playback flags in the same way. This would be easier to understand than the 100+ playback behaviour flags that are currently available.