Personally, I don't have any experience with VE (VisualEditor) and I don't see myself indulging in the mysteries of installing node.js, Parsoid, Restbase, and what not to get a shiner wikiEditor with some extra buttons but it is not to say that VE isn't useful to some users therefore the following contains some information about how to leverage VE in a SMW environment:
Any user with experience about using VE and SMW together is invited to comment on this ticket in order to disseminate information about how the two extension (can) work together.
I'm unable to say how good (or bad) they work together with SMW and/or VE but those extensions have clearly a SMW user in focus.
Well VE is still beta at best so I did not look into it closely either, but I believe that @jamesmontalvo3 and @darenwelsh have already worked with VE and gained some experience if I am not mistaken. This will become more of an issue since Hallo Welt is planning to switch to VE as the standard editor in one or two years time. Most probably @cicalese has worked with VE, too. Before I forget: @Seb35 :)
ping @pierreboutet who works on VEForPageForm
I began lately to study VE to better integrate it with other extensions, but it is a long and difficult path. For SMW specifically I didn’t know SemanticLinks and VeSMW – will test them. If we consider VE stable (I think we can without much risk) there is some dev+integration work to do for each SMW extension, I guess the basic thing is to create dialogs for each situation.
Extensibility can be tricky with Parsoid, as in order to natively render an extension parser feature inside VisualEditor (e.g. to get rid of artifacts like #1055) one must re-implement it in Parsoid. This can be done either fully within Parsoid [1] or by creating an MW API endpoint and calling it from Parsoid [2,3]. It seems Parsoid now provides a way to register such custom modules [4] but given the scarcity of relevant documentation it is hard to say whether this is still possible for potentially complex modules.
[1] [Cite as native Parsoid extension](https://github.com/wikimedia/parsoid/blob/master/lib/ext/Cite/index.js)
[2] [Portable Infobox Parsoid handler](https://github.com/Wikia/mediawiki-services-parsoid/blob/master/lib/ext.Infobox.js)
[3] [Portable Infobox API](https://github.com/Wikia/app/blob/dev/extensions/wikia/PortableInfobox/controllers/ApiPortableInfobox.class.php)
[4] [Parsoid config](https://github.com/wikimedia/parsoid/blob/master/lib/config/ParsoidConfig.js#L496)
If we consider VE stable (I think we can without much risk) there is some dev+integration
Having a vagrant (preferably an ova virtual box file to keep all the server technicalities at a minimum) setup which one can easily get an environment without the hassle of figuring out which VE works with which MediaWiki and Parsoid [0,1] would be the first step.
either fully within Parsoid [1] or by creating an MW API endpoint and calling it from Parsoid [2,3].
If we need a little API to get something done, I'm all ears but any major work on part of some VE integration should go in its own extension (as done so with Scribunto).
the scarcity of relevant documentation it is hard
Given that [2] is from 2014 and not one WMF employee has tried to given some hints or documentation, let alone a suggestion as to how to proceed, makes me question their motive in bringing integration to a wider audience.
[0] https://lists.wikimedia.org/pipermail/wikitech-l/2017-June/088271.html
[1] https://www.mediawiki.org/wiki/Topic:Tya05fh4fspi0vqs
[2] https://phabricator.wikimedia.org/T76278
Wearing my volunteer developer hat: I have only minimal experience with VisualEditor, and that experience is mostly from the user perspective - using it on wikis not maintained by me. But, as an experienced user of and code contributor to PageForms, I've always thought it would be great to have some integration between the Visual Editor and PageForms. I'm glad to see that VEForPageForm now exists, and I look forward to trying it out. I have not tried to use Visual Editor with Semantic MediaWiki, so I have not encountered or previously heard of the issue referenced by [2] above.
Wearing my newly minted Wikimedia Foundation hat: one of my goals is to ensure open lines of communication between the Foundation and volunteer developers. The difficulty of installing RESTBase needs to be addressed and ways to do so are being discussed. As for T76278, it appears that we are in agreement that, given appropriate guidance or documentation, a solution to that issue would be provided by a volunteer developer, not Foundation staff, since it relates specifically to the use of a non-Wikimedia extension. It is easy for tasks to languish in Phabricator if it isn't clear who should take action or what that action needs to be. I'll see if I can find somebody to provide documentation or guidance for that task. Are there any other outstanding issues that await attention with respect to getting VisualEditor and Semantic MediaWiki to coexist?
Okay, so @kghbln enabled the VisualEditor for the Extra namespace on the sandbox and my first edit with VE in that environment just calls for disaster.
Trying to add a simple [[Has text:: ... annotation ended up me having to enter a link in a popup which has nothing to do with an annotation. Yes, I could press cancel but I have the feeling this isn't going to work well and it just calls for errors.

Trying to add a simple {{ (as in {{#set... or {{#ask: ...) brings me to another popup (a template, really?) which has nothing to do with a parser function.

So, unless I missed something and there are some magic settings to make VE not popping up at each of my edits, I'm not feeling that comfortable and cannot see VE as that tool that would make me go all crazy about it.
PS: ... and, yes I could use the source editor but then why would I need Parsoid, RESTBase, node.js and all the other services just so that I end up in the old source editor?
So, unless I missed something and there are some magic settings to make VE not popping up at each of my edits, I'm not feeling that comfortable and cannot see VE as that tool that would make go all crazy about it.
What's the reason why I resisted trying out VE on wikis I control. It is the first time I dared to do this.
One thing we have to keep in mind to stay reasonably fair: VE is imho not tailored for intermediate to advanced users which SMW users probably have to be to make most out of it. I guess only novice users will not immediately come up with the idea of using parser functions on a wiki page so from this perspective triggering the template editor with {{-brackets sounds fair enough. Doing in-text annotations is probably an edge case in my logic since links also start with [[-brackets. However on wikis for novice users they will not come up with the idea either. So for WMF wikis ...
What is indeed of big interest to me too is how all the other users listening to this issue use the VE for intermediate and advanced editing, e.g. in the context of SMW and in light of your findings.
One thing we have to keep in mind to stay reasonably fair: VE is imho not tailored for intermediate to advanced users which SMW users probably have to be to make most out of it.
I buy this argument but the issue I have is that the wikiEditor development has been stalled (or frozen) and the only way to get a reasonable editor now is by making all the hoops just to end with the source editor that is comparable to the old wikiEditor with the difference that you have to care for of a lot of services that weren't originally necessary.
However on wikis for novice users they will not come up with the idea either. So for WMF wikis ...
While an organization like the WMF might need all the magic, I don't think doubling the administrative work for third-party users (those we are talking here) is justified in order to get an editor that is maintained and you not find yourself in phab queue with "Sorry, we don't do wikiEditor anymore but you might want to try the new source editor which comes as a VE bonus ...".
Let's go down to numbers, compare the time you need install the "old" wikiEditor and compare it with all the administrative work required to get the source editor (or VE) up and running including all the self study and documentation (opportunity costs) before you are able to make the first successful edit. What about doing a release update? ... and so on.
As I said, if you can switch to a "professional" editing mode (in VE) where I can write and not have to deal with all the popups, that might have an appeal but as of now my editing practice demands the source editor which brings me back to the discussion above.
I am all with you.
... but the issue I have is that the wikiEditor development has been stalled (or frozen) and the only way to get a reasonable editor now is by making all the hoops just to end with the source editor that is comparable to the old wikiEditor with the difference that you have to care for of a lot of services that weren't originally necessary.
While an organization like the WMF might need all the magic, I don't think doubling the administrative work for third-party users (those we are talking here) is justified in order to get an editor that is maintained and you find yourself in phab queue with "Sorry, we don't do wikiEditor anymore but you might want to try the new source editor which comes as a VE bonus ...".
This is indeed an issue of historical dimension because at the same time also the support of the classic edit toolbar is being removed, meaning that MediaWiki will get into a situation there it will be served with no editor or easily installable editor (classic edit toolbar, WikiEditor) at all. One will have to do great administrative backflips and on shared hosting you are just lost.
Most helpful comment
Extensibility can be tricky with Parsoid, as in order to natively render an extension parser feature inside VisualEditor (e.g. to get rid of artifacts like #1055) one must re-implement it in Parsoid. This can be done either fully within Parsoid [1] or by creating an MW API endpoint and calling it from Parsoid [2,3]. It seems Parsoid now provides a way to register such custom modules [4] but given the scarcity of relevant documentation it is hard to say whether this is still possible for potentially complex modules.
[1] [Cite as native Parsoid extension](https://github.com/wikimedia/parsoid/blob/master/lib/ext/Cite/index.js)
[2] [Portable Infobox Parsoid handler](https://github.com/Wikia/mediawiki-services-parsoid/blob/master/lib/ext.Infobox.js)
[3] [Portable Infobox API](https://github.com/Wikia/app/blob/dev/extensions/wikia/PortableInfobox/controllers/ApiPortableInfobox.class.php)
[4] [Parsoid config](https://github.com/wikimedia/parsoid/blob/master/lib/config/ParsoidConfig.js#L496)