Provide a workaround for any problem with the generated code
And allow the user to increase its markdown with things like <table>, but not necessarily convert all other elements in HTML
The idea would be to make a "compatibility mode" or "markdown mode", in wich the plugin would use the markdown syntax, and would just improve it with HTML on specific elements like :
Some of the text formatting (color, size).
Special caracters (exponent, etc).
Tables (<table>, <tr>, <td>, etc)
But it would use a regular markdown syntax on these elements :
New line (no <p> neither <div> or <br />, just a new line).
Bold
Italic
Bullet lists
Titles (h1, etc)
... and especially, for correct integration with the GRAV engine (urls, etc) :
Links
Images
Actual problems that such a mode could fix
Image sliding in the editor doesn't work : the plugin accept the native markdown injection but wraps it with <div>, this resulting in a rendering failure.
Image popups force the user to type the entire URI to the media (this forcing him to master HTML knowledge and to know exactly the path to the media ; not mentioning the laborious uselessness of such a task when it should basically know the path to the actual page and automatically fill it). Also, it results in a fixed URL, that can cause problem when moving from a development environment to a production environment, or to a production site to an other production site (all the content added during development in order to fulfill the application, will have to be rewritten to respect the new host URL).
Constant HTML replacing of the markdown can result in possible glitches in some contexts or complex structure, or can bring CSS issues because of unexpected HTML nesting.
And finally, the final client using the editor, cannot visualize nor master those problems, this causing the developer to dive in complex explanations on what to do or not to do with TinyMCE, and in painful manipulations for novices (like checking the generated code, removing some HTML elements for cleaning purpose, etc).
A last argument
If the main interests in using TinyMCE are to add the ability of creating <table>, and to colorize the text or to resize it (the rest can be done in Markdown), it should not systematically convert Markdown in HTML neither increase potential problems.
Image sizing, or CSS classes definition on an element, is natively supported by GRAV's markdown integration. Examples can be found in the online documentation : 
Suggestion
If creating a "Markdown mode", the WYSIWYG edition should be kept. Markdown editors are pretty disappointing for non-professional users, and TinyMCE should still provide an interesting improvement by avoiding user to deal with the strange markdown display.
In order to :
<table>, but not necessarily convert all other elements in HTMLThe idea would be to make a "compatibility mode" or "markdown mode", in wich the plugin would use the markdown syntax, and would just improve it with HTML on specific elements like :
<table>,<tr>,<td>, etc)But it would use a regular markdown syntax on these elements :
<p>neither<div>or<br />, just a new line).... and especially, for correct integration with the GRAV engine (urls, etc) :
Actual problems that such a mode could fix
Image sliding in the editor doesn't work : the plugin accept the native markdown injection but wraps it with
<div>, this resulting in a rendering failure.Image popups force the user to type the entire URI to the media (this forcing him to master HTML knowledge and to know exactly the path to the media ; not mentioning the laborious uselessness of such a task when it should basically know the path to the actual page and automatically fill it). Also, it results in a fixed URL, that can cause problem when moving from a development environment to a production environment, or to a production site to an other production site (all the content added during development in order to fulfill the application, will have to be rewritten to respect the new host URL).
Constant HTML replacing of the markdown can result in possible glitches in some contexts or complex structure, or can bring CSS issues because of unexpected HTML nesting.
And finally, the final client using the editor, cannot visualize nor master those problems, this causing the developer to dive in complex explanations on what to do or not to do with TinyMCE, and in painful manipulations for novices (like checking the generated code, removing some HTML elements for cleaning purpose, etc).
A last argument
If the main interests in using TinyMCE are to add the ability of creating
<table>, and to colorize the text or to resize it (the rest can be done in Markdown), it should not systematically convert Markdown in HTML neither increase potential problems.Image sizing, or CSS classes definition on an element, is natively supported by GRAV's markdown integration. Examples can be found in the online documentation :
Suggestion
If creating a "Markdown mode", the WYSIWYG edition should be kept. Markdown editors are pretty disappointing for non-professional users, and TinyMCE should still provide an interesting improvement by avoiding user to deal with the strange markdown display.