I’ve stumbled across an issue in the create_field function in core/fields/wysiwyg.php when the user editing a post with a WYSIWYG custom field has the visual editor disabled.
This happens when editing an existing post, as the data is stored correctly the first time, but to an unsuspecting user, would be modified to contain wrapping <p></p> tags.
On line 142, wp_richedit_pre is used, automatically populating the WYSIWYG field with the appropriate custom field, but then wraps it in <p></p> tags. When this is then saved, the <p> tags are stored in the custom field too.
In my case, this caused issues when using the WordPress oEmbed functions to convert YouTube URLs to embedded content.
The code in the create_field function should intelligently detect whether the user has the visual editor disabled or not, and as such should use the wp_htmledit_pre function instead of wp_richedit_pre if the user has the visual editor disabled.
The current code led to existing custom field content unexpectedly having paragraph tags added, and then stored with the content in the database.