According to this Khronos presentation, a "presentation engine" is:
The platform’s compositor or display engine
According to the specs:
The presentation engine is an abstraction for the platform’s compositor or display engine.
The presentation engine may be synchronous or asynchronous with respect to the application and/or logical device.
Some implementations may use the device’s graphics queue or dedicated presentation hardware to perform presentation.
Both these sources suggest that in most cases the presentation engine is a software entity ("abstraction") of the platform (which is itself, a software layer: the OS+window system).
Googling "window compositor display engine" provides me with this Wikipedia result, which seems relevant: https://en.wikipedia.org/wiki/Compositing_window_manager
Is that basically the article on "presentation engine"? For example, for Windows, the presentation engine would be Desktop Windows Manager, for a GNU/Linux system it could be Compiz, and so on? Or is it that the "presentation engine" is a combination the compositing manager and some other stuff?
Presentation engine in Vulkan is an external component that manages and accepts the rendered image you made in Vulkan (assumably) for the purposes of presentation to the user.
From another POV, it is whatever the interface gives you. Which is vkAcquireNextImageKHR, vkQueuePresentKHR, etc., in the case of the VK_KHR_swapchain extension. Other extensions can be made, as presentation engines that operate fundamentally differently emerge (e.g. VK_KHR_display_swapchain).
VK_KHR_swapchain, requires VK_KHR_surface, which is specialized to VK_KHR_win32_surface, VK_KHR_xlib_surface, etc. So you can bet those are the APIs the driver talks to underneath. I.e. it talks to Win32 API (aka Windows API), probably to the GDI component (but possibly to the DXGI swapchain). On linuxes + VK_KHR_xlib_surface, it would talk to X server. And so on... which inevitably has to end up in the hands of the windowing manager such as the DWM or Compiz.