Why does 'when' conditional test fail without jinja2 templating delimiters?

ansible 2.5.3 on OpenBSD 6.3 amd64
  config file = /etc/ansible/ansible.cfg
  configured module search path =
[u'/home/dspruell/.ansible/plugins/modules',
u'/usr/share/ansible/plugins/modules']
  ansible python module location =
/home/dspruell/.local/lib/python2.7/site-packages/ansible
  executable location = /home/dspruell/.local/bin/ansible
  python version = 2.7.14 (default, Mar 27 2018, 09:57:43) [GCC 4.2.1
Compatible OpenBSD Clang 5.0.1 (tags/RELEASE_501/final)]

Test playbook: the 'when' conditions on the sysctl tasks are how I
figured were proper to format the tests and avoid using jinja2
templating (and avoid subsequent warning from doing so):

Test playbook: the 'when' conditions on the sysctl tasks are how I
figured were proper to format the tests and avoid using jinja2
templating (and avoid subsequent warning from doing so):

---
- hosts: molodetz
  become: yes
  vars:
    sysctl_limit_semmns: kern.seminfo.semmns
    sysctl_limit_semmni: kern.seminfo.semmni
    postgres_limit_semmni: 60
    postgres_limit_semmns: 1024

  tasks:
    - name: check sysv semaphore system limits
      command: sysctl -n {{ sysctl_limit_semmni |quote }} {{
sysctl_limit_semmns |quote }}
      register: sem_limits
      changed_when: False

    - set_fact:
        semmni_cur_limit: '{{ sem_limits.stdout_lines[0]|int }}'
        semmns_cur_limit: '{{ sem_limits.stdout_lines[1]|int }}'
      changed_when: False

    - debug:
        var: '{{ item }}'
      loop:
        - semmni_cur_limit
        - semmns_cur_limit
        - postgres_limit_semmni
        - postgres_limit_semmns
        - 'postgres_limit_semmni > {{ semmni_cur_limit }}'
        - 'postgres_limit_semmns > {{ semmns_cur_limit }}'
        - 'postgres_limit_semmni > 100000'
        - 'postgres_limit_semmns > 100000'

    - name: set sysv max semaphore identifier system limit
      sysctl:
        name: '{{ sysctl_limit_semmni }}'
        value: '{{ postgres_limit_semmni }}'
        sysctl_set: yes
      when: postgres_limit_semmni > semmni_cur_limit

    - name: set sysv max semaphore count system limit
      sysctl:
        name: '{{ sysctl_limit_semmns }}'
        value: '{{ postgres_limit_semmns }}'
        sysctl_set: yes
      when: postgres_limit_semmns > semmns_cur_limit

This playbook results in the tasks being skipped because of evaluating
to false. The debug task shows the tests evaluating to true when using
jinja2 templating on the compared variable.

The semmni_cur_limit and semmns_cur_limit is strings and you need to cast/filter then through int each time you use them.
This is how Ansible/Jinga combo works at the time.

Here's how the second test playbook is modified to use templating
delimiters in the conditional:

$ diff -u test*.yml
--- test.yml Sat May 26 08:47:09 2018
+++ test2.yml Sat May 26 08:46:47 2018
@@ -35,12 +35,12 @@
         name: '{{ sysctl_limit_semmni }}'
         value: '{{ postgres_limit_semmni }}'
         sysctl_set: yes
- when: postgres_limit_semmni > semmni_cur_limit
+ when: postgres_limit_semmni > {{ semmni_cur_limit }}

     - name: set sysv max semaphore count system limit
       sysctl:
         name: '{{ sysctl_limit_semmns }}'
         value: '{{ postgres_limit_semmns }}'
         sysctl_set: yes
- when: postgres_limit_semmns > semmns_cur_limit
+ when: postgres_limit_semmns > {{ semmns_cur_limit }}

This is not supported in Jinja you can't use {{ }} inside {{ }}.

With jinja2 templating delimiters the comparison evaluates to true and
executes the tasks, but results in the warning. Is there a different
way to structure the conditional properly?

   when: postgres_limit_semmns > semmns_cur_limit | int

Also would like to understand why do these set_facts still result in
the values being strings instead of integers?

- set_fact:
    semmni_cur_limit: '{{ sem_limits.stdout_lines[0]|int }}'
    semmns_cur_limit: '{{ sem_limits.stdout_lines[1]|int }}'

That is just how Jinja work.
In Jinja 2.10 some new feature is added to support native type, support in Ansible is probably coming in 2.7.

https://github.com/ansible/ansible/pull/32738

This is enlightening and helped make adjustments. Thanks!