SUMMARY
 
Virtual keyboard implementation (via text_input extension) forces compositor-side input method handling on wayland clients, without offering other input methods at compositor side, e.g. ibus or compose. Plasma UI offers to disable virtual keyboard, from which I assumed that it disables text_input extension at the compositor (but it doesn't), so clients can use text composing at client-side in this case. Here is a work-in-progress patch https://codereview.qt-project.org/#/c/248181/ for Qt, which detects that text-input extension has been unloaded and hence should fallback to the normal QT_IM_MODULE handling at client-side (see reconfigureInputContext()). What kwin does instead is (see m_enabled):

void VirtualKeyboard::show()
{
    if (m_inputWindow.isNull() || !m_enabled) {
        return;
    }
    m_inputWindow->setGeometry(screens()->geometry(screens()->current()));
    qApp->inputMethod()->show();
}

The author clearly did not think about supporting other input methods when keyboard is "disabled". And did not provide a way to really disable it. From clients points of view it is never disabled. Clients do not get any messages when clicking on enable/disable vkb.

text_input extension means that compositor claims that it will handle all keyboard input composing at compositor side, but kwin's implementation cares only about virtual keyboard. This means that compose key (dead key) sequences will not work, and ibus for e.g. Chinese input also won't work, even though compositor claims that it will handle everything. If compositor instead would unload the extension when user selects to disable vkb support from the menu, then Qt could fallback to handling 'ibus', 'compose' *or any other input method which supports QT_IM_MODULE) at client-side.

QT_IM_MODULE is unset on default KDE neon env. When unset, and if compositor claims to support text-input, then Qt won't do any text composing locally. If Qt application is started with QT_IM_MODULE set to something, then Qt will use that input method instead. Setting QT_IM_MODULE to 'compose' is the current workaround for enabling compose keys, but will disable vkb support in that application. 

Other solution is that Kwin should add not only an option to disable vkb, but also a way to switch from vkb to ibus for example. Then it can keep text_input always loaded, just switch input methods at compositor-side. 

Addition details:

qtwayland:

 commit 5444ea50bb2b1b894d5b3c33676f9ef207fdcd1a
 Author: Jan Arne Petersen <jan.petersen@kdab.com>
 Date:   Wed Dec 30 00:08:17 2015 +0100

    Fix text-input support for new API
    
    Update text input support to upstream text-input protocol v2 from
    wayland-protocols. Remove support for input-method protocol for now.
    
    Map text-input protocol on compositor side to the Qt input method API,
    this allows to use any qt platform input method on compositor side
    (especially qtvirtualkeyboard). Add support for qtvirtualkeyboard to
    pure-qml example.
    
    Implement all missing functions of the text-input protocol.
    
    Change-Id: I597451ff65454a63dff86026b6a8d1ffbe07ce02
    Done-with: Zeno Endemann <zeno.endemann@kdab.com>
    Reviewed-by: Giulio Camuffo <giulio.camuffo@kdab.com>

=========================================

kwin:

 commit f26f2fe181ae0500a9105ad0864d1f3062d0d30c 
 Author: Martin Gräßlin <mgraesslin@kde.org>
 Date:   Fri Apr 29 15:05:03 2016 +0200

    Integrate QtVirtualKeyboard into KWin/Wayland
   
    Summary:
    The idea is to have KWin provide a virtual keyboard. To support this
    KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
    QPA plugin loads it.
   
    KWin has a new class VirtualKeyboard which acts as the focus object and
    the "proxy" for input methods. The QPA plugin ensures that this is the
    focusObject, so that all input method related events are sent to this
    class. From there it will be possible to delegate to other applications
    through the Wayland interfaces.

==========================================

So on Dec, 2015 Qt project added support for "any qt platform input method on compositor side" (see QWaylandTextInput), while few months later (Apr, 2016) KDE added a less complete solution to KWin. KWin supports only a vkb at compositor side, because they map IM APIs to wayland wire inside virtualkeyboard.cpp, without any generalization (see https://phabricator.kde.org/R108:f26f2fe181ae0500a9105ad0864d1f3062d0d30c)

text_input_2 protocol is for any input method handling at compositor-side, it is not virtual-keyboard-only protocol. Furthermore, upstream even has removed any vkb support from text_input_v3 (which is a topic for discussion on its own) and some individual is working on a dedicated protocol for vkb handling.

The main point is - KWin compositor needs fixing.