The device no longer asks permission to use location. Verified that location settings were not turned off or disabled on the device.
When testing with an older device using 4.0.4 version the geolocation works as expected.

Need to research to see if there's a new permission JS API or somesuch to get user permission to use location in the browser.

Tested with ICEfaces 4 trunk r48851. Android 6.0.1 nexus 5 device.
When in debug mode some console warnings are seen. getCurrentPosition() and watchPosition() are deprecated on insecure origins. The application must be accessed in a secure manner such as https://...
After deploying the demo on a SSL enabled server, the device then asked for access to location and the demo performed as expected.

coalesced.js.jsf?ln=ice.core&dgst=xe4dyo:1061 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
VM115:3 
Launching getCurrentPosition, maxAge: 3600000(ms), timeout: 30000(ms) highAccuracy: undefined
VM115:4 getCurrentPosition() and watchPosition() are deprecated on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details.

coalesced.js.jsf?ln=ice.core&dgst=xe4dyo:2114 The deviceorientation event is deprecated on insecure origins, and support will be removed in the future. You should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details.

Excellent. Okay, marking this resolved with the requirement to host the application via SSL as a Known Issue.

Will add this to the Wiki docs for the component.

FYI, here is the explanation from Google, as well some indicators that localhost is exempt (not useful when testing mobile devices):

Src: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

Proposal

We want to start applying the concepts in https://w3c.github.io/webappsec-secure-contexts/to features that have already shipped and which do not meet the (new, not present at the time) requirements. In particular, this approximately requires that powerful features only be accessible on "secure origins" (such as HTTPS) where the full ancestor chain is also secure.

We want to start by requiring secure origins for these existing features:
Geolocation — requires secure origins as of M50
Device motion / orientation
EME
getUserMedia
AppCache

As with gradually marking HTTP as non-secure, we expect to gradually migrate these features to secure-only, based on thresholds of usage, starting with lowest usage and moving towards higher. We also expect to gradually indicate in the UX that the features are deprecated for non-secure origins.

The deprecation strategy for each of these features is not decided on and may very well differ from feature to feature. We don’t currently know what the thresholds will be, or how heavily used the features are on what kinds of origins. We are in the process of gathering data, and will report back when we have it. There are no firm plans at all at this time, other than eventual deprecation. We intend for this to stimulate a public discussion of the best way to approach this deprecation. So, to that point, we'd love to hear what the community thinks.
Testing a Deprecated Powerful Feature

After a feature has been deprecated, if you are a developer that needs to keep testing a feature on a server that does not have a valid certificate, you have two options:
localhost is treated as a secure origin over HTTP, so if you're able to run your server from localhost, you should be able to test the feature on that server.
You can run chrome with the --unsafely-treat-insecure-origin-as-secure="http://example.com" flag (replacing "example.com" with the origin you actually want to test), which will treat that origin as secure for this session. Note that you also need to include the --user-data-dir=/test/only/profile/dir to create a fresh testing profile for the flag to work.

I added the following warning to the mobi:geolocation and mobi:camera wiki pages for this issue:

Recent browser releases have begun restricting access to certain powerful features, including geolocation tracking, to make them only accessible when the page content accessed via "secure origins" (such as HTTPS), where the full ancestor chain is also secure. See https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins for more information.

Due to this change, this component now requires that your ICEfaces application is accessed using HTTPS protocol from the browser.