Shared neovim/nvim and vim config-file, issue with coc.nvim: "(coc-definition)" works in vim - but not in neovim, why?

Question

Noob, please bear over with me: I'm trying to share my ~/.vimrc config by sourcing it from ~/.config/nvim/init.vim. I try to use coc.nvim and it works for vim, but not for neovim/nvim (using a sourced config-file). I don't know where to look or what is the problem. The ~/.config/nvim/init.vim is:

set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath=&runtimepath
source ~/.vimrc

The ~/.vimrc file:

call plug#begin('~/.vim/plugged')
Plug 'neoclide/coc.nvim', {'branch': 'release'}
call plug#end()

" Get LSP support:
let g:coc_start_at_startup = 0
augroup coc
  autocmd!
  autocmd VimEnter * :silent CocStart
augroup end

" ---=== Below is directly from: https://github.com/neoclide/coc.nvim ===---
nmap <silent> gd <Plug>(coc-definition)
nmap <silent> gy <Plug>(coc-type-definition)
nmap <silent> gi <Plug>(coc-implementation)
nmap <silent> gr <Plug>(coc-references)

1. If I open a source code file using vim, after around 10 seconds in the lower left corner it says: "[coc.nvim] FORTLS initialization complete", which tells that the LSP/language server is now running, it's working and I can use the "coc-definition" etc commands to jump around.
2. If I open exactly the same file using nvim, it doesn't work: I wait and wait, it never says "initialization complete" and also the "gd" or "coc-definition" commands won't work, so I can't jump around...

Seems like nvim isn't loading the FORTLS (language server), but vim is? Why? How can I debug this or understand what is wrong? Thanks for any ideas!

UPDATE: Someone downvoted this question: I'm not trying to be disrespectful, I appreciate instead please giving me constructive feedback, if I should rephrase - but I've edited the original post, to make things clearer. Also: I suspect neovim/nvim isn't loading ~/.vim/coc-settings.json but I thought sourcing like shown would fix that and is it possible to see some kind of vim/neovim initialization log? So, the /home/user/.vim/coc-settings.json must be okay (since vim uses it). I also found out that I could "debug" a bit using the output from ":CocInfo" - this also reveals that the language server using nvim doesn't start at all... There are no errors/warnings, just nothing happens - the difference should be very clear from the below?

=== 1: vim ===
## versions

vim version: VIM - Vi IMproved 8.2 8022380
node version: v15.7.0
coc.nvim version: 0.0.80-1e2652e725
coc.nvim directory: /home/user/.vim/plugged/coc.nvim
term: dumb
platform: linux

## Log of coc.nvim

2021-02-19T21:39:22.868 INFO (pid:1355597) [services] - registered service "languageserver.fortran"
2021-02-19T21:39:22.872 INFO (pid:1355597) [services] - fortran state change: stopped => starting
2021-02-19T21:39:22.907 INFO (pid:1355597) [plugin] - coc.nvim 0.0.80-1e2652e725 initialized with node: v15.7.0 after 100ms
2021-02-19T21:39:22.913 INFO (pid:1355597) [language-client-index] - Language server "languageserver.fortran" started with 1355608
2021-02-19T21:39:27.165 INFO (pid:1355597) [attach] - receive notification: showInfo []


=== 2: nvim ===
## versions

vim version: NVIM v0.4.4
node version: v15.7.0
coc.nvim version: 0.0.80-1e2652e725
coc.nvim directory: /home/user/.vim/plugged/coc.nvim
term: xterm-256color
platform: linux

## Log of coc.nvim

2021-02-19T21:39:59.762 INFO (pid:1355680) [plugin] - coc.nvim 0.0.80-1e2652e725 initialized with node: v15.7.0 after 113ms
2021-02-19T21:40:02.607 INFO (pid:1355680) [attach] - receive notification: showInfo []

Answer 1

Oops, sorry guys - I did write I'm a new user. I figured out the problem, after I realized I could get some kind of "debug" output with ":CocInfo". The solution was just to:

cd ~/.config/nvim
ln -s ~/.vim/coc-settings.json .

It means that the

set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath=&runtimepath
source ~/.vimrc

Probably only works for normal vim-stuff - and coc.nvim has a special configuration file "coc-settings.json" that isn't sourced and nvim will not search in the runtimepath, which I didn't find to be intuitive... I'll leave the answer here, if another noob does the same silly mistake and finds this...